Eric Johnson wrote:
Ortwin,
It is an odd problem. Not quite a dead-lock in the traditional sense.
One thread is waiting on the other, and the other is waiting for the
garbage collector. It just so happens that the garbage collector will
never kick in, because the first thread happens to be
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he
hadn't done). There is however a fallback whereby when a
HttpConnection is garbage collected (ie: when we discover that it is no
longer in use), it
Adrian Sutton wrote:
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he hadn't
done). There is however a fallback whereby when a HttpConnection is
garbage collected (ie: when we discover that it is no
Also, connections release themselves when there is no more data to be
read from the stream.
The solution in this case is to always call releaseConnection() when
you're finished with the connection (as is mentioned lots and lots
through our docs :) and I really can't see any better way to deal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-06-19 14:54 ---
Are there any objections, comments to this patch?
Oleg
Okay with me. Maybe UPPERCASE the BitSet identifier?
-
To unsubscribe,
Yep. Static variables should be in upper case. Will be done.
Oleg
-Original Message-
From: Ortwin Glck [mailto:[EMAIL PROTECTED]
Sent: Thu 6/19/2003 17:03
To: Commons HttpClient Project
Cc:
Subject:Re: DO NOT REPLY [Bug 20481] - HttpClient does not properly
Hey Adrian,
Thanks for responding. Contrib class would fine and I
would be willing to do it. Do you have a suggestion on a
name? I agree with your assessment about configurating
the whole can of worms, but some solution was better than
none. The only other thing I could think of would be
Eric,
I would rather keep web.xml file parsing out. We have to maintain compatibility with
Java 1.2.2 for which JAXP is an optional component. I do not think we should introduce
JAXP as a dependency for HttpClient.
Oleg
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20665.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20665.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20665.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Thanks a lot for that Eric. I've got it in a virtual sticky for the
moment and hopefully will do up a proper page for the site over the
weekend. Rest assured though that it hasn't been ignored (those damn
virtual stickys just never seem to go away...).
Regards,
Adrian Sutton.
On Tuesday,
Mike,
There still exists x0A0 characters. (LF?)
Here I made a patch for it.
Sincerely,
-- Tetsuya ([EMAIL PROTECTED])
P.S. I sent the same mail to commons-dev.
-
On 19 Jun 2003 23:37:16 -
(Subject: cvs commit:
Howdy all,
I'm having some trouble pinpointing the exact cause of an exception I'm
getting from HttpClient, it seems to be related to connection
management with MultiThreadedConnectionManager so I thought I'd draw on
the expertise here. :)
Essentially, we have an invalid HTTP server
Quite right.
Thanks,
Mike
On Thursday, June 19, 2003, at 08:10 PM, Tetsuya Kitahata wrote:
Mike,
There still exists x0A0 characters. (LF?)
Here I made a patch for it.
Sincerely,
-- Tetsuya ([EMAIL PROTECTED])
P.S. I sent the same mail to commons-dev.
Hello,
I have been putting together a (relatively) comprehensive documentation
of NTLM and its use in various protocols; this is now up and available at:
http://davenport.sourceforge.net/ntlm.html
I figured there might be interest on this list; it only touches briefly
on NTLM HTTP
Eric,
Thanks for pointing this out. I will add a link to it to the
HttpClient NTLM authentication for those who are curious about the more
technical details.
Regards,
Adrian Sutton.
On Friday, June 20, 2003, at 11:12 AM, Eric wrote:
Hello,
I have been putting together a (relatively)
Adrian,
I'm looking into to this and I agree it is quite strange. The part I
don't understand is why the second attempt to write to the socket
fails. The socket is not being closed on the HttpClient side until
after the failure occurs. Any thoughts on how the connection is being
closed?
On Friday, June 20, 2003, at 11:41 AM, Michael Becke wrote:
Adrian,
I'm looking into to this and I agree it is quite strange. The part I
don't understand is why the second attempt to write to the socket
fails. The socket is not being closed on the HttpClient side until
after the failure
Hey Adrian,
Ok, but what about what something below?
MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; +
/something );
mpm.addParameter( A, new File( /usr/dev/images/add.gif ) );
How do I set the content type for the file? It seems either the
addParameter needs to
Eric,
You want to create the FilePart manually and then add it to the
MultipartPostMethod. Something like:
MultipartPostMethod mpm = new MultipartPostMethod(
http://localhost:8080/something; );
FilePart part = new FilePart(name, file, contentType, charset);
mpm.addPart(part);
Mike
On
Yup, I'm trying it on OS X and linux. I think the problem is in
HttpMethodBase.execute() in particular the following line:
if (responseStream != null) {
responseStream.close();
}
Since there is no content length or chunking the response stream is
not being wrapped and is
I have another problem with proxies in that even if
shouldCloseConnection() returns true, the connection to the proxy
isn't actually closed and I'm not sure why. Any hints about where
proxy connections are closed?
Ah, ignore this bit. I'd screwed up the test case so it added a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20938.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
27 matches
Mail list logo
