Re: [Bugzilla] vs [JIRA] revisited
Folks, As a result of the discussion my assumption is that we want to go ahead with migration from Bugzilla to JIRA. If you have any objections or concerns it is the right time to voice them. I am going to update the change request http://issues.apache.org/jira/browse/INFRA-74 shortly stating out intention to proceed with the migration if no one speaks out. Oleg On Mon, 2004-10-11 at 16:12, Oleg Kalnichevski wrote: Folks Due to the recent upgrade of HttpClient to a full project in Bugzilla JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA still a newer and more flexible system which can potentially make our life and that of our users simpler. http://nagoya.apache.org/jira/browse/INFRA-74 The only fundamental gripe with JIRA that some folks have is that it is not open-source. I do not think we should try to be holier than the Pope himself, since too many projects have already defected to JIRA Religious reasons aside, I also foresee technical difficulties too. Currently (at least with Bugzilla 2.14.2) there appears no way to make a project completely read-only. Submission of new reports can be disabled, but one can still modify the existing bug reports. There is a few options: (1) Ask folks to resubmit their comments in JIRA when important / ignore modifications made in Bugzilla when unimportant. (2) Tweak Bugzilla a little to prevent mutation of existing reports. Note, supposedly Apache Bugzilla is already a fork. So, the real trouble here is to convince the Infrastructure folks to apply a patch, and more importantly reapply it every time Bugzilla is upgraded. Now, the REAL REAL trouble is that it almost took a full scale nuclear conflict between the Evil Russian Empire (me) and the Freedom Alliance (the Infrastructure team) to implement what turned out to be a fairly minor change to get HttpClient promoted to a project status. From now on, I am deeply skeptical about everything that has to do with Bugzilla maintenance. Besides, I may not survive yet another squabble with Noel. (3) Wait until other Jakarta Commons project migrate first. Long may be the wait, though So, what's the popular opinion on that? Non-committers are highly encouraged to voice their opinion too Evil Comrade Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31783] New: - http.connection-manager.timeout is a LONG not an INTEGER
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31783. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31783 http.connection-manager.timeout is a LONG not an INTEGER Summary: http.connection-manager.timeout is a LONG not an INTEGER Product: HttpClient Version: 3.0 Alpha 2 Platform: Other URL: http://jakarta.apache.org/commons/httpclient/3.0/prefere nce-api.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Commons HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Documentation is wrong. Table in Preference Architecture page states http.connection-manager.timeout is an Integer. Doing: setParameter(http.connection-manager.timeout, new Integer(n)); Causes: java.lang.ClassCastException at org.apache.commons.httpclient.params.DefaultHttpParams.getLongParameter (DefaultHttpParams.java:171) at org.apache.commons.httpclient.params.HttpClientParams.getConnectionManagerTimeo ut(HttpClientParams.java:143) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDirector.java:161) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:437) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:324) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31783] - http.connection-manager.timeout is a LONG not an INTEGER
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31783. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31783 http.connection-manager.timeout is a LONG not an INTEGER [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |3.0 Beta 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31607] - Catch SocketTimeoutException not InterruptedIOException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31607. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31607 Catch SocketTimeoutException not InterruptedIOException [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-19 18:12 --- Patch committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31783] - http.connection-manager.timeout is a LONG not an INTEGER
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31783. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31783 http.connection-manager.timeout is a LONG not an INTEGER [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-19 18:23 --- Fix applied to CVS HEAD. Many thanks, Paul Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it possible to send and email using HTTPCLIENT?
Can I just send a multipart post to an email server with attached files using Httpclient? Would this work for an email? If so, does anyone have an example of doing this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Version Not Supported Error
Mike, I have taken your advise and set the content length manually sending in the length of a file even if it is larger than 2 gigs. I am getting a bug however when uploading over 2 gigs still. It seems that the server is blocking the read function for the ServletInputStream. I get a socket read time out exception thrown. When I look at the bytes that were written and the length of the file, the bytes that were written seem to be more than the length of the file. This only occurs for files over 2 gigs. I tested multiple files, (512 MB, 1.8 GB, 2.0 GB). On the client side I have checked my code for the file input stream and writing of the bytes to the request output stream. The bytes I am writing are consistent with the length of the file, yet I am having this trouble on the server side. I am using HttpServlet on the server side of my application. I am getting the input stream from the request input stream, I am creating a file output stream, and I am writing to the file. I believe that the HttpServlet should be compatible with HTTP 1.1. Still, from my previous threading problem I had to set the setHttp11 function to false so that I do not get the upload error I stated before. Sorry for the questions, but I have tried fixing this and understanding it to no avail. I appreciate any help that you could give me. Thanks for your time, N. Jarvis From: Michael Becke [EMAIL PROTECTED] Reply-To: Commons HttpClient Project [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Subject: Re: HTTP Version Not Supported Error Date: Mon, 18 Oct 2004 11:10:48 -0400 Hi Nick, I have one addition to Roland's comments. b) Don't call setContentLength, or set it to -1 in a FilePart object. This should work fine with HTTP/1.1 and chunked encoding, but also with HTTP/1.0 and no chunked encoding. Since the server does not know the content length in advance, it has to read until the end of the stream in no-chunks mode. Connection re-use is impossible, but after transferring more than 2 gigs I doubt you'll notice the performance impact of opening a new connection :-) It might be a violation of HTTP to POST data without a valid content length, but since you're controlling the server as well, that shouldn't bother you much. The HttpClient 2.0 API does not directly support setting content length 2GB because of the use of an int. This has been fixed in the 3.0 API but it can be done in 2.0 by setting the content-length header manually: method.setRequestHeader(Content-Length, Some number bigger than 2GB); Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Version Not Supported Error
Hi Nick, Sounds like there may be a problem with the server side. What server are you using? Mike On Oct 19, 2004, at 6:04 PM, Nick Jarvis wrote: Mike, I have taken your advise and set the content length manually sending in the length of a file even if it is larger than 2 gigs. I am getting a bug however when uploading over 2 gigs still. It seems that the server is blocking the read function for the ServletInputStream. I get a socket read time out exception thrown. When I look at the bytes that were written and the length of the file, the bytes that were written seem to be more than the length of the file. This only occurs for files over 2 gigs. I tested multiple files, (512 MB, 1.8 GB, 2.0 GB). On the client side I have checked my code for the file input stream and writing of the bytes to the request output stream. The bytes I am writing are consistent with the length of the file, yet I am having this trouble on the server side. I am using HttpServlet on the server side of my application. I am getting the input stream from the request input stream, I am creating a file output stream, and I am writing to the file. I believe that the HttpServlet should be compatible with HTTP 1.1. Still, from my previous threading problem I had to set the setHttp11 function to false so that I do not get the upload error I stated before. Sorry for the questions, but I have tried fixing this and understanding it to no avail. I appreciate any help that you could give me. Thanks for your time, N. Jarvis From: Michael Becke [EMAIL PROTECTED] Reply-To: Commons HttpClient Project [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Subject: Re: HTTP Version Not Supported Error Date: Mon, 18 Oct 2004 11:10:48 -0400 Hi Nick, I have one addition to Roland's comments. b) Don't call setContentLength, or set it to -1 in a FilePart object. This should work fine with HTTP/1.1 and chunked encoding, but also with HTTP/1.0 and no chunked encoding. Since the server does not know the content length in advance, it has to read until the end of the stream in no-chunks mode. Connection re-use is impossible, but after transferring more than 2 gigs I doubt you'll notice the performance impact of opening a new connection :-) It might be a violation of HTTP to POST data without a valid content length, but since you're controlling the server as well, that shouldn't bother you much. The HttpClient 2.0 API does not directly support setting content length 2GB because of the use of an int. This has been fixed in the 3.0 API but it can be done in 2.0 by setting the content-length header manually: method.setRequestHeader(Content-Length, Some number bigger than 2GB); Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
