Re: [VOTE] suspend use of @author tags

2004-03-17 Thread Ortwin Glück
+1

Michael Becke wrote:

Given the current ambiguity regarding @author tags I propose that we  
suspend their use for contributors without a CLA on file.  This is  
meant to be a temporary solution until something official is endorsed  
by the ASF board.

Mike

 --
 Vote:  Suspend use of @author tags
 [ ] +1 I am in favor of the proposal
 [ ] -1 I am against this proposal (must include a reason).
  
 --

-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]
--
 _
 NOSE applied intelligence ag
 ortwin glück  [www]  http://www.nose.ch
 software engineer [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp id]   0x81CF3416
 8005 zürich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
Hello,
i using the HttpClient in a Java Applet but
if i transfer a file larger then 32MB i get a OutOfMemory.

does some others has the same bug?

greetz from Germany

Martin

Re: OutOfMemory if using PUT

2004-03-17 Thread Ortwin Glück
Martin,

please have a look at this example:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/ChunkEncodedPost.java?rev=1.4.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=auto

(link may be wrapped)

Kind regards

Ortwin Glück

martin hilpert wrote:

Hello,
i using the HttpClient in a Java Applet but
if i transfer a file larger then 32MB i get a OutOfMemory.
does some others has the same bug?

greetz from Germany

Martin
--
 _
 NOSE applied intelligence ag
 ortwin glück  [www]  http://www.nose.ch
 software engineer [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp id]   0x81CF3416
 8005 zürich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
Hallo Ortwin so schnell findet man sich wieder,
du hast in der einen Java NG geantwortet


http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/Ch
unkEncodedPost.java?rev=1.4.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=aut
o



gruß martin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: OutOfMemory if using PUT

2004-03-17 Thread Kalnichevski, Oleg

Martin,
The problem is most likely caused by the PUT method buffering the request body in 
order to determine its length

You can avoid this problem by 

(1) using chunk-encoding

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/ChunkEncodedPost.java?rev=1.4.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup

(2) explicitly specifying the content length

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/UnbufferedPost.java?rev=1.2.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup

Oleg

-Original Message-
From: martin hilpert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 11:09
To: [EMAIL PROTECTED]
Subject: OutOfMemory if using PUT


Hello,
i using the HttpClient in a Java Applet but
if i transfer a file larger then 32MB i get a OutOfMemory.

does some others has the same bug?

greetz from Germany

Martin

***
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]



Re: OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
Hello Oleg,

 The problem is most likely caused by the PUT method buffering the request
body in order to determine its length

that means there is no work around WITH PUT ?


 You can avoid this problem by

 (1) using chunk-encoding


http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/Ch
unkEncodedPost.java?rev=1.4.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=mar
kup

 (2) explicitly specifying the content length


http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/Un
bufferedPost.java?rev=1.2.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=marku
p

that are both POST requests?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemory if using PUT

2004-03-17 Thread Ortwin Glück


martin hilpert wrote:
that means there is no work around WITH PUT ?
The two alternatives ARE the work around!

that are both POST requests?
The same applies to PUT methods as well as PUT basically works the same 
as POST.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
ok first thank it work now with files larger 32mb,
but there is still a another problem.

if the user transfer a large file like 32MB over a normal DSL connection
(128kbit up / 796 kbit down)

how could i find out how many bytes are send?

is there anyway?

martin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
Hi Ortwin,
 Not from within HttpClient directly. You can however simply wrap your 
 stream and count the bytes read through the respective methods.
 how can i wrap it?
any sampel code?

thx

martin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemory if using PUT

2004-03-17 Thread Ortwin Glück


martin hilpert wrote:

Hi Ortwin,

Not from within HttpClient directly. You can however simply wrap your 
stream and count the bytes read through the respective methods.
 how can i wrap it?
any sampel code?
Errm... Ever heard of the java.io.FilterInputStream class? It is 
intended to be a base class for such a thing linke you need. If you are 
using Swing you can just use javax.swing.ProgressMonitorInputStream.

O.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemory if using PUT

2004-03-17 Thread martin hilpert
Hi,
yes i heard about that class.
no i dont use any swing control,
i use awt.


 Errm... Ever heard of the java.io.FilterInputStream class? It is 
 intended to be a base class for such a thing linke you need. If you are 
 using Swing you can just use javax.swing.ProgressMonitorInputStream.
i dont understand how i can monitor the stream.

HttpClient client = new HttpClient();
PutMethod put = new PutMethod(zielurl);
FileInputStream fin =new FileInputStream(C:\test.jpg);
put.setRequestBody(fin);
put.setRequestContentLength(PutMethod.CONTENT_LENGTH_CHUNKED);
client.executeMethod(put);
System.out.print(put.getResponseBodyAsString());
put.releaseConnection();




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemory if using PUT

2004-03-17 Thread Ortwin Glück


martin hilpert wrote:
i dont understand how i can monitor the stream.

HttpClient client = new HttpClient();
PutMethod put = new PutMethod(zielurl);
FileInputStream fin =new FileInputStream(C:\test.jpg);
  MonitorInputStream min = new MonitorInputStream(fin);
put.setRequestBody(fin);
put.setRequestContentLength(PutMethod.CONTENT_LENGTH_CHUNKED);
client.executeMethod(put);
System.out.print(put.getResponseBodyAsString());
put.releaseConnection();
class MonitorInputStream extends FilterInputStream {

   public MonitorInputStream(InputStream in) {
  super(in);
   }
   ...

   public  int  read(byte[] b, int off, int len) {
 int bytesRead = super.read(b, off, len);
 ... do what you like with bytesRead now ...

 return bytesRead;
   }
}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


TestWebappBasicAuth fails on IIS

2004-03-17 Thread Dan Tran
Hello, I think IIS rejects any Basic Authentication request.  Is there a way
to configure IIS to allow these
request to passthru to httpclient servlets?

Any suggestions?

-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: 2.0 rc1 leaking sockets?

2004-03-17 Thread Eric Bloch
Thanks... just to be clear though... the multi-threadded connection mgr 
should never hold open more than a fixed number of sockets though, right?

I've got a case where there's a clear socket leak in the java process 
and someone is pointing at me right now (and I use httpclient and always 
release my connections).

-Eric

Michael Becke wrote:

Hi Eric,

The multi-threaded connection manager holds on to connections that 
have been released, but it does not necessarily close them.  
Connections are only closed if the server sends a connection: close 
header or if HTTP 1.0 is used.

There are currently two open bugs that may apply to your situation:

http://issues.apache.org/bugzilla/show_bug.cgi?id=25372
  and
http://issues.apache.org/bugzilla/show_bug.cgi?id=27589
I would also suggest checking the archive for more discussion on this 
matter.

Mike

On Mar 16, 2004, at 7:31 PM, Eric Bloch wrote:

Hi there,

I've got a question.  I'm using the Multithreaded Connection Manager 
and I know that I'm always calling releaseConnection() on every 
connection I use.  Are there any reports (or possibilities) that 
releaseConnection() will fail to close an open socket or lose track 
of is such that I will see socket leaks?   This is running against 
JRE 1.3.1 (on linux).

I have a custy that is seeing leaks WebSphere and at the moment, 
httpclient is the current suspect since it's one of the few things in 
the app that causes it to open sockets.

Thanks,
-Eric
-
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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level

2004-03-17 Thread Adrian Sutton
On 18/3/04 12:54 AM, Jeff Dever [EMAIL PROTECTED] wrote:

 Just the active ones.  You must leave off Sun-gu and Sean, since they
 don't have CLA on file their committer status has been suspended.  I
 agree with Oleg about the handling of the others.

Sounds good to me.  I'll take care of chasing down the committers that are
in the current draft proposal this afternoon.  I'll also do up a second
draft proposal with the feedback I've received.

Thanks for all the feedback.

 -jsd

Regards,

Adrian Sutton.

===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 27589] - MultiThreadedConnectionManager should provide a shutdown

2004-03-17 Thread bugzilla
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=27589.
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=27589

MultiThreadedConnectionManager should provide a shutdown





--- Additional Comments From [EMAIL PROTECTED]  2004-03-17 22:51 ---
Mike, the multithreaded connection manager of yours is still a sort of a black
art to me ;-) But from what I can tell, the patch looks fine. The decision
whether the patch is safe to be included it into 2.0 branch can only rest with
you, as you are the one who knows the code best

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] suspend use of @author tags

2004-03-17 Thread Eric Johnson
Well, hmmm - I'm perfectly happy to have my name removed, or sign a CLA.

My quick scan of the files revealed what I suspect is a much longer list 
of authors that probably haven't signed a CLA than just those two that 
you indicate.

Rewriting the code is a drastic and expensive solution!  I would think 
that we only go there in case of clear infringement, not just because 
there might be.  My understanding (courtesy of Groklaw), is that with 
normal copyright infringement there must be the opportunity to remedy 
the infringement before any damages kick in.  That point, I think, it 
would be the time to consider replacing code.  At least, that is what I 
understand of US law (of course, IANAL).

-Eric.

Jeff Dever wrote:

+1

Additionally, we should seek to contact those currently in @author 
tags that do not have a CLA on file, and ask permission that they be 
removed or to encourage them to sign a CLA.  I'll do this.

BTW: If we can't get either of these to things from a contributor 
(Sean and Sun-Gu at this point) then we will probablly should rewrite 
any code that can be attributed to them.

-jsd

Ortwin Glück wrote:

+1

Michael Becke wrote:

Given the current ambiguity regarding @author tags I propose that 
we  suspend their use for contributors without a CLA on file.  This 
is  meant to be a temporary solution until something official is 
endorsed  by the ASF board.

Mike

 
--
 Vote:  Suspend use of @author tags
 [ ] +1 I am in favor of the proposal
 [ ] -1 I am against this proposal (must include a reason).
  
 
--

-
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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: 2.0 rc1 leaking sockets?

2004-03-17 Thread Michael Becke
On Mar 17, 2004, at 5:05 PM, Eric Bloch wrote:

Thanks... just to be clear though... the multi-threadded connection 
mgr should never hold open more than a fixed number of sockets though, 
right?
Yes, any one instance of MultiThreadedHttpConnectionManager will only 
have a certain number of open connections.  This is configurable via 
setMaxTotalConnections().  You will need to ensure that you are reusing 
the same instance of the connection manager.

There were also a number of bugs fixed in the 
MultiThreadedHttpConnectionManager between 2.0 RC1 and the final 2.0 
relase.  I would suggest upgrading to 2.0 just to be sure.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 27589] - MultiThreadedConnectionManager should provide a shutdown

2004-03-17 Thread bugzilla
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=27589.
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=27589

MultiThreadedConnectionManager should provide a shutdown





--- Additional Comments From [EMAIL PROTECTED]  2004-03-18 04:23 ---
Yes, it has become pretty complicated.  These changes are pretty safe I think, and are 
needed to fix a 
hole in the current 2.0 distribution.  I will make a few more documentation 
enhancements and apply the 
patch, if there are no objections.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: 2.0 rc1 leaking sockets?

2004-03-17 Thread Eric Bloch
Hey Michael,

Thanks .. I am using setMaxConnectionsPerHost()... and not 
setMaxTotalConnections().  Assuming there is a fixed number of hosts, 
will there be a fixed number of sockets used ?

Also were there any API or behavioral changes (besides bug fixes :-)) 
between 2.0 rc1 and final that I should be aware of?  Or is there a doc 
somewhere that has the list of changes between rc1 and final? 

Thanks again!

-Eric

Michael Becke wrote:

On Mar 17, 2004, at 5:05 PM, Eric Bloch wrote:

Thanks... just to be clear though... the multi-threadded connection 
mgr should never hold open more than a fixed number of sockets 
though, right?


Yes, any one instance of MultiThreadedHttpConnectionManager will only 
have a certain number of open connections.  This is configurable via 
setMaxTotalConnections().  You will need to ensure that you are 
reusing the same instance of the connection manager.

There were also a number of bugs fixed in the 
MultiThreadedHttpConnectionManager between 2.0 RC1 and the final 2.0 
relase.  I would suggest upgrading to 2.0 just to be sure.

Mike

-
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]