Re: Java can leak...
I think the reality here is that the only way to reliably track down the problem is to actually profile the original application that is seeing the problem. There's really not a lot of point in me profiling HttpClient separately because I've not seen any problem with memory leaks so they're not likely to suddenly turn up in profiling. The particular way HttpClient is being used is likely what's bringing out the leak whether the leak is caused by HttpClient code or not. Jan, if you could do some profiling work on your application to identify at least (a) that it is that particular app and not something else on the machine (pretty easy) (b) what types of objects are hanging around and (c) what's still got a reference on them, that would really help track down the problem. The profiling that we've done on our app doesn't show any indication of a problem with HttpClient but the way we use HttpClient is extremely different. Regards, Adrian Sutton. On Friday, May 30, 2003, at 08:49 AM, Wilcox, Mark wrote: Jan, Good point. With Java you don't have to remember as much about silly things like malloc and free in C/C++ which led to all sorts of problems. However, you do have to worry about GC, object creation and holding on to objects for too long. Something like HPJMeter may help in analyzing the problem: http://www.hp.com/products1/unix/java/developers/hpjmeter.html Mark -Original Message- From: Jan Gonsalves [mailto:[EMAIL PROTECTED] Sent: Thu 5/29/2003 6:09 PM To: Commons HttpClient Project Cc: Subject: Java can leak... Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java can leak...
My impression of your first email was that the server had used up the 4GB of memory. Are you saying it was HttpClient? If so, you must have run the JVM and specified the max heap size to something like -Xmx4GB. If that's the case then this is probably something you don't want to do. Once Java gets over the minimum heap size, specified by -Xms, it will continue to expand all the way up to the max, even if it doesn't need to. Once the JVM allocates memory to the heap it never releases it. Is this what's happening? Mike On Thursday, May 29, 2003, at 06:09 PM, Jan Gonsalves wrote: Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java can leak...
We need to do more investigation on our side for sure, I just wanted to know if anyone had noticed memory leaks over long recycled connections. The JVM my app runs in alots 768Mb as the max, but I work in conjunction with serveral apps. I'm the only app using HttpClient. When I run and I really get going processing large chunks of data memory usage for the system really takes a hit. My personal memory footprint based off qps for linux says I max out at about 380mb. If I loose a reference to an object ROOT has, does that count against my memory usage or does that consume memory but no under a particular JVM? My personal belief is that my app does things a new way in our system and I'm putting stress on other objects in the system that aren't normally accustomed to it and they are having difficulty. Anyone know of a good, user friendly (read inexperienced to memory profilling) application? Jan Michael Becke wrote: My impression of your first email was that the server had used up the 4GB of memory. Are you saying it was HttpClient? If so, you must have run the JVM and specified the max heap size to something like -Xmx4GB. If that's the case then this is probably something you don't want to do. Once Java gets over the minimum heap size, specified by -Xms, it will continue to expand all the way up to the max, even if it doesn't need to. Once the JVM allocates memory to the heap it never releases it. Is this what's happening? Mike On Thursday, May 29, 2003, at 06:09 PM, Jan Gonsalves wrote: Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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] - 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: Fw: BETA-1 is officially out
go for it -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Michael Becke [EMAIL PROTECTED] wrote on 30/05/2003 12:24:31 PM: Yes, I have it if you would like. Should I upload it to cvs.apache.org and make it readable? Mike On Thursday, May 29, 2003, at 10:17 PM, [EMAIL PROTECTED] wrote: Will hopefully get to this today. Have downloaded jdk 1.2.2 to build the dist., but if you guys have one ready to go, please email it to me. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Michael Becke [EMAIL PROTECTED] wrote on 29/05/2003 10:35:58 PM: If you could also push the distribution to http://jakarta.apache.org/builds/jakarta-commons/release/commons- httpclient/v2.0/ that would be good. The newly published site now references this directory for downloading Beta 1. Thanks for your help dIon. Mike On Thursday, May 29, 2003, at 02:55 AM, [EMAIL PROTECTED] wrote: Unless Jeff comes back into the fold in the short term, I'll happily help here. I'll start by checking out the tagged code and doing a maven site:deploy. Let me know if there are problems with this -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - Forwarded by dIon Gillard/Multitask Consulting/AU on 29/05/2003 04:52 PM - Michael Becke [EMAIL PROTECTED] wrote on 29/05/2003 11:13:40 AM: dIon, Any assistance that you could lend would be greatly appreciated. Pretty much everything that we can take care of has been done. We've tagged the release, tested the code, updated the site docs, and written an announcement. I think all that's left to be done is run maven to generate the new site and distribution, upload the new files, add the news item, and mail a notice to the usual mailing lists. The code has been tagged as HTTPCLIENT_2_0_BETA1. The announcement is below (note that one link still needs to be added). Jeff wrote release procedures for the last release if you would like to take a look at them (http://jakarta.apache.org/commons/httpclient/releases.html). Please let us know if you have any questions. Thank you, Mike release announcement - The Commons team is pleased to announce the first feature complete Beta 1 release of Commons HttpClient 2.0 from the Apache Software Foundation. Commons HttpClient is an Open Source implementation of the Hyper-Text Transfer Protocol(HTTP), one of the most widely used communication protocols underpinning the World Wide Web. This release contains a number of bug fixes and feature enhancements. For more details please see the release notes(LINK HERE). Source and binary distributions are available from the main Jakarta site http://jakarta.apache.org/builds/jakarta-commons/release/commons- httpclient/v2.0/. Please see the HttpClient http://jakarta.apache.org/commons/httpclient/ web site for more information. end of release announcement - On Wednesday, May 28, 2003, at 07:59 PM, [EMAIL PROTECTED] wrote: Oleg, I probably have permissions on the jakarta site and file directories too...Let me know if I can help. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Kalnichevski, Oleg [EMAIL PROTECTED] wrote on 29/05/2003 01:29:07 AM: Folks Beta-1 has been tagged on the CVS trunk two days ago and is officially out. The problem is that we are unable to deploy the official build without Jeff Jandalf, our project lead, as only he has necessary access permissions for the official Jakarta file repository web site. You can still obtain beta-1 snapshot from the CVS directly by running the following command: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co -r HTTPCLIENT_2_0_BETA1 jakarta-commons/httpclient Cheers Oleg - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0-beta1 files have been uploaded
Does anyone else have access to jakarta-site2? I do, but I'd rather take the input from the team for the release details. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au [EMAIL PROTECTED] wrote on 30/05/2003 02:07:42 PM: Done. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - 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: Re: Help on client authentication
Sorry for the delay. Typically in an SSL transaction the client
wants to authenticate the server (validating server certificates).
However in the case of mutual client authentication the server
also authenticates the client (using client certificates) in
addition to the client authenticating the server . Checkout
http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/JSSERefGuide.html
and
http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/samples/sockets/client/SSLSocketClientWithClientAuth.java
for more info on this.
My problem relates to a SocketException when I run a custom ssl
socket factory with client authentication.
In a previous release of http client, the HttpClient class had a
setSSLSocketFactory method. So we used to be able to create a
custom SSLSocketFactory that supported client Authentication and
set it to be used with an instance HttpClient class. Something
like-
HttpClient hc = new HttpClient();
try
{
SSLContext ctx;
KeyManagerFactory kmf;
KeyStore ks;
char[] passphrase = passphrase.toCharArray();
ctx = SSLContext.getInstance(TLS);
kmf = KeyManagerFactory.getInstance(SunX509);
ks = KeyStore.getInstance(JKS);
ks.load(new FileInputStream(testkeystore),
passphrase);
kmf.init(ks, passphrase);
ctx.init(kmf.getKeyManagers(), null, null);
SSLSocketFactory factory = ctx.getSocketFactory();
hc.setSSLSocketFactory(factory);
}
catch (Exception e)
{
throw new IOException(e.getMessage());
}
Then use get and PostMethod...
In HttpClient 2.0 beta1, I tried to create a
CustomSocketFactory on similar lines to
EasySSLProtocolSocketFactory example provided at
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/
Something like..
class MyFactory implements SecureProtocolSocketFactory
{
private javax.net.ssl.SSLSocketFactory factory;
MyFactory()
{
mFactory = getFactoryWithClientAuth();
}
private static SSLSocketFactory
getFactoryWithClientAuth()
{
...//same way as in Jsse example
}
public Socket createSocket(Socket socket,String host,
int port, boolean autoClose)
throws IOException,UnknownHostException
{
return mFactory.createSocket( socket, host,
port,
autoClose);
}
// implement the rest of createSocket Methods similarly as
above
.
}
I then used to post stuff.
PostMethod post = new PostMethod(postServerUrl);
post.setRequestBody(Test http client);
post.setRequestHeader(Content-type, text/plain);
Protocol strictHttps = new Protocol( https, new MyFactory(),
443);
HttpClient client = new HttpClient();
HostConfiguration hostc = new HostConfiguration();
hostc.setHost(ServerUrl,443,strictHttps);
client.executeMethod(hostc,post);
When I ran the second example against 2.0 Beta1, the protocol
interactions in the out seem to be correct,
I saw all the SSL handshake stuff work correctly...
*** ClientHello, v3.1
*** ServerHello, v3.1
*** Certificate chain
*** CertificateRequest
*** ServerHelloDone
*** ClientKeyExchange
*** CertificateVerify
*** Finished, v3.1
except just after the last stage when its about to the actual
post I get
*** Finished, v3.1
verify_data: { 98, 86, 46, 20, 159, 191, 251, 102, 9, 201, 95,
201 }
***
[write] MD5 and SHA1 hashes: len = 16
: 14 00 00 0C 62 56 2E 14 9F BF FB 66 09 C9 5F C9
bV.f.._.
Plaintext before ENCRYPTION: len = 32
: 14 00 00 0C 62 56 2E 14 9F BF FB 66 09 C9 5F C9
bV.f.._.
0010: A2 FE 98 4F 4D E1 1B AD 0D 74 DD 5A 44 54 E9 3D
...OMt.ZDT.=
main, WRITE: SSL v3.1 Handshake, length = 32
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.close()
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.closeSockedAndStreams()
main, SEND SSL v3.1 ALERT: warning, description = close_notify
Plaintext before ENCRYPTION: len = 18
: 01 00 AB 04 44 A2 B3 5D A4 89 16 62 F8 11 47 D6
D..]...b..G.
0010: A6 E4 ..
main, WRITE: SSL v3.1 Alert, length = 18
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.close()
2003/05/30 01:02:59:124 EDT [TRACE] HttpConnection - -enter
HttpConnection.closeSockedAndStreams()
java.net.SocketException: Software caused connection abort:
JVM_recv in socket input stream read
at java.net.SocketInputStream.socketRead0(Native
Method)
at
java.net.SocketInputStream.read(SocketInputStream.java:116)
at
com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
at
com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at
RE: Java can leak...
Jan, Let me elaborate. No doubt one can still do silly things in Java that may lead to severe memory problems. However, the point I was trying to make is that Java applications do not 'leak' memory in a way non-GC applications do. One can easily starve a java application of heap memory if object allocation de-allocation strategy is flawed. However, no java application should ever consume memory above the limit specified with -Xmx option, unless there is a bug in JVM. I guess you should try narrowing down the problem somewhat. At the moment all we can do is to speculate. If you absolutely positive that the problem is somehow triggered by HttpClient, please let us know some more details on your application's execution environment: OS version, JVM version, application server or servlet engine used, and so on. Oleg -Original Message- From: Jan Gonsalves [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 00:09 To: Commons HttpClient Project Subject: Java can leak... Oleg, I understand what you mean my mem alloc, but Java can leak, it's a proven fact. Anytime ROOT has a reference to something it makes it unable to GC, however, if you loose your reference and ROOT still has it's, that's a memory leak. ROOT will never GC that memory. Ask youself this, if Memory leaks were impossible in JAVA, how can programs such as JProfiler or OptimizIt sell? Jan Oleg Kalnichevski wrote: Jan, HttpClient is a pure Java application and as such does not manage memory allocation directly. I suggest that you check if there are any known issues with the jvm you are using. Upgrading to HttpClient beta-1 would not hurt, anyways. Oleg On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote: Does anyone know of any memory issues with opening a connection and continuely re-using it, only closing it when a socket timeout happens? I'm currently using ALPHA 3. I have to fake out a browser and navigate through a website to extract information because they don't offer a straight DB connection. I re-use this connection the whole time, never closing it, only recycling it, unless I get a socket timeout, ConnectionException, or HTTPRecoverableException. Our Production server has 4GB of ram. Last night we ran and the system went down to 4MB free, 4! I'm just wondering if I'm leaking due to HTTP Client. I've gone over my stuff and it looks relatively solid, I'm wondering now if I'm using HttpClient incorrectly. Does Beta 1 help with any memory issues? Jan Gonsalves - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0-beta1 files have been uploaded
Awesome. Thanks for the help dIon. I'm not sure about site2. How could one determine this? Mike On Friday, May 30, 2003, at 12:17 AM, [EMAIL PROTECTED] wrote: Does anyone else have access to jakarta-site2? I do, but I'd rather take the input from the team for the release details. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au [EMAIL PROTECTED] wrote on 30/05/2003 02:07:42 PM: Done. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - 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]
