xlightweb-develop — xLightweb Support Forum

[Xlightweb-develop] WebSockets support for xLightweb released

[Gregor R. <gre...@gm...>]

Hi,

WebSockets support for xLightweb has just been released. The new web socket extension of xLightweb implements the current Web Socket protocol draft. It includes Web Socket support for the client-side and server-side. 

Gregor

Re: [Xlightweb-develop] Handling CONNECT requests

[Gregor R. <gre...@gm...>]

Hi Erin,

do you know the HttpProxy example (http://xlightweb.svn.sourceforge.net/viewvc/xlightweb/xlightweb/sandbox/HttpProxy/)? This proxy implements the connect handling based on the HttpUtils convenience method establishTcpTunnel(..)

Gregor 

----- Original Message -----
From: Erin Drummond
Sent: 02/01/10 01:35 AM
To: xli...@li...
Subject: [Xlightweb-develop] Handling CONNECT requests

Hi,

I am trying to write a transparent proxy using xlightweb. So far I
have it mostly working for every site that doesnt use https/ the
CONNECT method.
I have used the ForwardHandler and ReverseHandler example in the
Tutorial to implement the proxy with a few minor modifications as
follows:

In the ForwardHandler, I first check if the request method is CONNECT.
If it is, the HttpClient has SSLContext.getDefaultContext() passed to
its constructor. If not, I just use a standard HttpClient (no
parameters passed to the constructor).

The request appears to get forwarded correctly, however the remote
server responds with "400 Bad Request" if using the HttpClient with
SSLContext, or "501 Not Implemented" if using the standard HttpClient.

I have tried with removeHopByHopHeaders() and without.

A typical conversation looks like:
ForwardHandler: Got request: CONNECT www.google.com:443 HTTP/1.1

Host: www.google.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7)
Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7

Proxy-Connection: keep-alive

ReverseHandler: Got response: HTTP/1.1 400 Bad Request

Server: GFE/2.0

Date: Mon, 01 Feb 2010 00:24:14 GMT

Content-Length: 1350

Content-Type: text/html; charset=UTF-8

X-XSS-Protection: 0

Cache-Control: private, x-gzip-ok=""

How can I proxy HTTPS connections/connections which use the CONNECT
method? I was not able to find this in the tutorial documentation.

Cheers,
Erin

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Xlightweb-develop mailing list
Xli...@li...
https://lists.sourceforge.net/lists/listinfo/xlightweb-develop

[Xlightweb-develop] Handling CONNECT requests

[Erin D. <eri...@gm...>]

Hi,

I am trying to write a transparent proxy using xlightweb. So far I
have it mostly working for every site that doesnt use https/ the
CONNECT method.
I have used the ForwardHandler and ReverseHandler example in the
Tutorial to implement the proxy with a few minor modifications as
follows:

In the ForwardHandler, I first check if the request method is CONNECT.
If it is, the HttpClient has SSLContext.getDefaultContext() passed to
its constructor. If not, I just use a standard HttpClient (no
parameters passed to the constructor).

The request appears to get forwarded correctly, however the remote
server responds with "400 Bad Request" if using the HttpClient with
SSLContext, or "501 Not Implemented" if using the standard HttpClient.

I have tried with removeHopByHopHeaders() and without.

A typical conversation looks like:
ForwardHandler: Got request: CONNECT www.google.com:443 HTTP/1.1

Host: www.google.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7)
Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7

Proxy-Connection: keep-alive



ReverseHandler: Got response: HTTP/1.1 400 Bad Request

Server: GFE/2.0

Date: Mon, 01 Feb 2010 00:24:14 GMT

Content-Length: 1350

Content-Type: text/html; charset=UTF-8

X-XSS-Protection: 0

Cache-Control: private, x-gzip-ok=""


How can I proxy HTTPS connections/connections which use the CONNECT
method? I was not able to find this in the tutorial documentation.

Cheers,
Erin

Re: [Xlightweb-develop] is HttpClient thread-safe?

[Ben V. <ben...@gm...>]

Great, thanks! (And sorry for the needless question.)

-- Ben V.

On Mon, Dec 28, 2009 at 4:01 AM, Gregor Roth <gre...@gm...> wrote:
> Hello Ben,
>
> the HttpClient is thread-safe (see JavaDoc). The BodyDataSink/DataSource is
> not (if you using it).
>
> Gregor
>
>
>
> ----- Original Message -----
>
> From: Gregor Roth
>
> Sent: 12/27/09 09:05 PM
>
> To: Ben Vandervalk
>
> Subject: [Xlightweb-develop] is HttpClient thread-safe?
>
>
>
> Hi all,
>
> Just wondering, is the xLightweb HttpClient thread-safe? (I'm using 2.10).
>
> Fantastic library, btw :-) I needed something for issuing asynchronous
> HTTP requests and this is the only library that actually works.  (I
> also tried innovation.ch, which seems to have deadlock issues, and the
> jetty http client, which throws IO exceptions when there are a large
> number of simultaneous connections.)
>
> -- Ben Vandervalk
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Xlightweb-develop mailing list
> Xli...@li...
> https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>
>

Re: [Xlightweb-develop] is HttpClient thread-safe?

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] is HttpClient thread-safe?

[Ben V. <ben...@gm...>]

Hi all,

Just wondering, is the xLightweb HttpClient thread-safe? (I'm using 2.10).

Fantastic library, btw :-) I needed something for issuing asynchronous
HTTP requests and this is the only library that actually works.  (I
also tried innovation.ch, which seems to have deadlock issues, and the
jetty http client, which throws IO exceptions when there are a large
number of simultaneous connections.)

-- Ben Vandervalk

Re: [Xlightweb-develop] Problem migrating from xlightweb 2.8 to xlightweb 2.10

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] Problem migrating from xlightweb 2.8 to xlightweb 2.10

[Idoia U. O. <iu...@se...>]

Hi,

We were using the class  org.xlightweb. MultipartFormDataRequest included in xlightweb-2.8.0-jar-with-dependencies.jar, but this class doesn't seem to be included in xlightweb-2.10.1-jar-with-dependencies.jar. Is there any strategy to migrate the code which uses this class?

BTW, we migrate to 2.10 to use HTTPCompression (org.xlightweb.client. HttpClient setAutoUncompress method)

Best regards and merry Christmas!

Idoia Usoz
SEMANTIC SYSTEMS
Avda. Txoriherri 9-2º. Edificio Arteaga
48160 Derio Vizcaya
Tel.: +34 94 454 55 50
Fax: +34 94 454 55 51
iu...@se...<mailto:tt...@se...>
www.semantic-systems.com<http://www.semantic-systems.com>


________________________________
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.


This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it.

Re: [Xlightweb-develop] Pipelining

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] Pipelining

[trancemotions <tra...@gm...>]

I'm aware that pipelining is only supported on servers that implement
HTTP/1.1 and that this can be accomplished using asynchronous client calls
in xLightweb.  My question is: does checking to make sure the server
supports 1.1 the responsibility of the programmer or is this handled under
the hood by xLightweb (ie if the server is 1.0 it executes the requests
sequentially)?

I checked through the archive as well as the documentation and wasn't able
to find a suitable answer.  If this has indeed been asked/answered
previously I apologize!

Thanks,

-Steve

P.S. - To those who designed and implemented this library:  Great work!

Re: [Xlightweb-develop] Delay in sendInternal

[Kunal E. <kun...@ya...>]

Hi Gregor,

Apologies for late reply.
I checked with the test code you sent, it works fine.

Here is my finding:
The day I was testing with your test code and later with my application, I was working on local machine(http server on local m/c), so it worked all-fine,
no delay. Also had done some (2) modifications to my app to coincide with test code viz. removed pool.setActive() and registerPool(). 
So I was happy :)

The next day when I was testing with http server on other m/c there was a delay :(, so tried reverting those 2 modifications and retried, so confirmed that those changes are not affecting delay.

-- The actual thing is that, if in GET request relative path is used e.g. /doesNotExist.html  "&&" the server connecting to is not local m/c, I observe the 5 second delay, if you use local m/c as server this will not be observed.
-- If GET is constructed with absolute path (IHttpRequest request = new GetRequest("http://10.3.3.99:8090/index") ) , irrespective of local/other server, there is no delay .. :)


Didn't see in details but:
GET with absolute path would set host and port and when send is called,
send(IHttpRequest request, IHttpResponseHandler responseHandler) --> enhanceHeader(requestHeader) --> header.getHost()  would try to fetch from underlying tcp connection (if relative URL is provided), don't know whether this could cause that delay.
 

Thanks,
~Kunal




________________________________
From: Gregor Roth <gre...@gm...>
To: Kunal Ekawde <kun...@ya...>
Sent: Thu, November 26, 2009 8:31:57 PM
Subject: Re: [Xlightweb-develop] Delay in sendInternal


Hi Kunal,

I have tried to reproduce this. See http://xlightweb.svn.sourceforge.net/viewvc/xlightweb/xlightweb/core/trunk/src/test/java/org/xlightweb/HttpClientConnectionBuildOnTcpConTest.java?view=markup. However, I was not able to reproduce your reported behaviour. Please cross-check the test class

Gregor 



----- Original Message -----
>From: Kunal Ekawde
>Sent: 11/25/09 07:46 am
>To: gre...@go...
>Subject: Re: [Xlightweb-develop] Delay in sendInternal
> Hi Gregor,
>
>I had captured log with FINE log level in app server (glassfish) for  org.xlightweb and org.xsocket, here is the log details, a few line of which were posted in my first mail.
>Hope it helps; let me know if more details are required.
>
>
>[#|2009-11-24T13:12:19.436+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Composed fwd GET request|#]
>
>[#|2009-11-24T13:12:19.442+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoConnector|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.IoConnector;MethodName=connectAsync;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|try to connect /10.3.3.99:80 (connect timeout 24 d)|#]
>
>[#|2009-11-24T13:12:19.480+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.ConnectionManager|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.ConnectionManager;MethodName=register;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|connection registered|#]
>
>[#|2009-11-24T13:12:19.481+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=register;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] add new connection to register task queue|#]
>
>[#|2009-11-24T13:12:19.483+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=getSelectionKey;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] key is null|#]
>
>[#|2009-11-24T13:12:19.484+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnection|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.NonBlockingConnection;MethodName=init;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] connection 3279534412524e787771611293eCa created. IoHandler: (/10.3.3.99:80 -> /10.3.1.92:49683) SUSPENDED received=0 bytes, sent=0 bytes, age=4 millis, lastReceived=13:12:19,479, sendQueueSize=0 bytes [3279534412524e787771611293eCa]|#]
>
>[#|2009-11-24T13:12:19.484+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=31;_ThreadName=xDispatcherClientGlb#0;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=registerHandlerNow;_RequestID=6e6186cb-796c-48d5-b349-82a17d7ef381;|[3279534412524e787771611293eCa] registering connection|#]
>
>[#|2009-11-24T13:12:19.491+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnectionPool|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnectionPool$Pool;MethodName=register;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] added to managed pool (active=1, idle=0)|#]
>
>[#|2009-11-24T13:12:19.492+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnectionPool|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnectionPool$NativeConnectionHolder;MethodName=init;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] pooled connection created (size=1, active=1, pooledIdleTimeoutMillis=2147483647, pooledLifeTimeout=2147483647): id=3279534412524e787771611293eCaremote=/10.3.3.99(/10.3.3.99:80)|#]
>
>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Got a non blockconnection|#]
>
>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|About to FWD the GET request|#]
>
>[#|2009-11-24T13:12:19.508+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppConnHandler|_ThreadID=32;_ThreadName=xNbcPool-1-thread-9;|Connect successful|#]
>
>[#|2009-11-24T13:12:24.103+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.client.HttpClientConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.client.HttpClientConnection;MethodName=sendInternal;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] sending (bodyless): GET /index HTTP/1.1 Host: 10.3.3.99:80 User-Agent: xLightweb/2.9.1|#]
>
>[#|2009-11-24T13:12:24.104+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.AbstractHttpConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.AbstractHttpConnection;MethodName=write;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] TCP write: GET /index HTTP/1.1
>Host: 10.3.3.99:80
>User-Agent: xLightweb/2.9.1|#]
>
>[#|2009-11-24T13:12:24.106+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnection;MethodName=internalFlush;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] flushed|#]
>
>
>
>Thanks,
>~Kunal
>
>________________________________
>From: "gre...@go..." 
>To: Kunal Ekawde 
>Cc: xli...@li...
>Sent: Wed, November 25, 2009 10:33:06 AM
>Subject: Re: [Xlightweb-develop] Delay in sendInternal
>
>
>Hello Kunal,
>
>if possible, please activate the debug log of xLightweb (->namespace org.xlightweb). to get more information
>
>
>Gregor 
>
>
>----- Original Message -----
>>From: Kunal Ekawde
>>Sent: 11/24/09 03:13 pm
>>To: xli...@li...
>>Subject: [Xlightweb-develop] Delay in sendInternal
>> Hi,
>>
>>I observe a delay of 5 seconds (constant) everytime the send function of HttpClientConnection(non_blocking_connection) is invoked.
>>
>>
>>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Got a non blockconnection|#]
>>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|About to FWD the GET request|#]
>>[#|2009-11-24T13:12:19.508+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppConnHandler|_ThreadID=32;_ThreadName=xNbcPool-1-thread-9;|Connect successful|#]
>>[#|2009-11-24T13:12:24.103+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.client.HttpClientConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.client.HttpClientConnection;MethodName=sendInternal;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] sending (bodyless): GET /index HTTP/1.1Host: 10.3.3.99:80 User-Agent: xLightweb/2.9.1
>>
>>
>>The only suspicion i see is in addMessageHeaderHandler:
>>
>>private void sendInternal(IHttpRequest request, IHttpResponseHandler responseHandler) throws IOException, ConnectException {
>>addMessageHeaderHandler(new MessageHeaderHandler(new ResponseHandlerAdapter(responseHandler, request.getRequestHeader()), request.getRequestHeader(), responseTimeoutMillis));
>>
>>........
>>}
>>
>>At application I have (excerpt without error handling):
>>pool = new NonBlockingConnectionPool();
>>nbc = pool.getNonBlockingConnection(host, port, new Handler());
>>con = new HttpClientConnection(nbc); 
>>con.send(request, null);
>>
>>My question is whether it is expected delay or doing some modifications, that delay could be avoided?
>>
>>~Kunal
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------------
>>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>>trial. Simplify your report design, integration and deployment - and focus on 
>>what you do best, core application coding. Discover what's new with
>>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>_______________________________________________
>>Xlightweb-develop mailing list
>>Xli...@li...
>>https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>>
>
>
>
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>trial. Simplify your report design, integration and deployment - and focus on 
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Xlightweb-develop mailing list
>Xli...@li...
>https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>


      

Re: [Xlightweb-develop] Delay in sendInternal

[Kunal E. <kun...@ya...>]

Hi Gregor,

I had captured log with FINE log level in app server (glassfish) for  org.xlightweb and org.xsocket, here is the log details, a few line of which were posted in my first mail.
Hope it helps; let me know if more details are required.


[#|2009-11-24T13:12:19.436+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Composed fwd GET request|#]

[#|2009-11-24T13:12:19.442+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoConnector|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.IoConnector;MethodName=connectAsync;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|try to connect /10.3.3.99:80 (connect timeout 24 d)|#]

[#|2009-11-24T13:12:19.480+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.ConnectionManager|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.ConnectionManager;MethodName=register;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|connection registered|#]

[#|2009-11-24T13:12:19.481+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=register;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] add new connection to register task queue|#]

[#|2009-11-24T13:12:19.483+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=getSelectionKey;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] key is null|#]

[#|2009-11-24T13:12:19.484+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnection|_ThreadID=27;_ThreadName=xConnector#default;ClassName=org.xsocket.connection.NonBlockingConnection;MethodName=init;_RequestID=c7f70510-d66b-4d4a-aa30-7cb53a27592a;|[3279534412524e787771611293eCa] connection 3279534412524e787771611293eCa created. IoHandler: (/10.3.3.99:80 -> /10.3.1.92:49683) SUSPENDED received=0 bytes, sent=0 bytes, age=4 millis, lastReceived=13:12:19,479, sendQueueSize=0 bytes [3279534412524e787771611293eCa]|#]

[#|2009-11-24T13:12:19.484+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.IoSocketDispatcher|_ThreadID=31;_ThreadName=xDispatcherClientGlb#0;ClassName=org.xsocket.connection.IoSocketDispatcher;MethodName=registerHandlerNow;_RequestID=6e6186cb-796c-48d5-b349-82a17d7ef381;|[3279534412524e787771611293eCa] registering connection|#]

[#|2009-11-24T13:12:19.491+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnectionPool|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnectionPool$Pool;MethodName=register;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] added to managed pool (active=1, idle=0)|#]

[#|2009-11-24T13:12:19.492+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnectionPool|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnectionPool$NativeConnectionHolder;MethodName=init;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] pooled connection created (size=1, active=1, pooledIdleTimeoutMillis=2147483647, pooledLifeTimeout=2147483647): id=3279534412524e787771611293eCaremote=/10.3.3.99(/10.3.3.99:80)|#]

[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Got a non blockconnection|#]

[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|About to FWD the GET request|#]

[#|2009-11-24T13:12:19.508+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppConnHandler|_ThreadID=32;_ThreadName=xNbcPool-1-thread-9;|Connect successful|#]

[#|2009-11-24T13:12:24.103+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.client.HttpClientConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.client.HttpClientConnection;MethodName=sendInternal;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] sending (bodyless): GET /index HTTP/1.1 Host: 10.3.3.99:80 User-Agent: xLightweb/2.9.1|#]

[#|2009-11-24T13:12:24.104+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.AbstractHttpConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.AbstractHttpConnection;MethodName=write;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] TCP write: GET /index HTTP/1.1
Host: 10.3.3.99:80
User-Agent: xLightweb/2.9.1|#]

[#|2009-11-24T13:12:24.106+0530|FINE|sun-glassfish-comms-server2.0|org.xsocket.connection.NonBlockingConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xsocket.connection.NonBlockingConnection;MethodName=internalFlush;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCa] flushed|#]



Thanks,
 ~Kunal

________________________________
From: "gre...@go..." <gre...@go...>
To: Kunal Ekawde <kun...@ya...>
Cc: xli...@li...
Sent: Wed, November 25, 2009 10:33:06 AM
Subject: Re: [Xlightweb-develop] Delay in sendInternal


Hello Kunal,

if possible, please activate the debug log of xLightweb (->namespace org.xlightweb). to get more information


Gregor 


----- Original Message -----
>From: Kunal Ekawde
>Sent: 11/24/09 03:13 pm
>To: xli...@li...
>Subject: [Xlightweb-develop] Delay in sendInternal
> Hi,
>
>I observe a delay of 5 seconds (constant) everytime the send function of HttpClientConnection(non_blocking_connection) is invoked.
>
>
>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Got a non blockconnection|#]
>[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|About to FWD the GET request|#]
>[#|2009-11-24T13:12:19.508+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppConnHandler|_ThreadID=32;_ThreadName=xNbcPool-1-thread-9;|Connect successful|#]
>[#|2009-11-24T13:12:24.103+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.client.HttpClientConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.client.HttpClientConnection;MethodName=sendInternal;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] sending (bodyless): GET /index HTTP/1.1Host: 10.3.3.99:80 User-Agent: xLightweb/2.9.1
>
>
>The only suspicion i see is in addMessageHeaderHandler:
>
>private void sendInternal(IHttpRequest request, IHttpResponseHandler responseHandler) throws IOException, ConnectException {
>addMessageHeaderHandler(new MessageHeaderHandler(new ResponseHandlerAdapter(responseHandler, request.getRequestHeader()), request.getRequestHeader(), responseTimeoutMillis));
>
>........
>}
>
>At application I have (excerpt without error handling):
>pool = new NonBlockingConnectionPool();
>nbc = pool.getNonBlockingConnection(host, port, new Handler());
>con = new HttpClientConnection(nbc); 
>con.send(request, null);
>
>My question is whether it is expected delay or doing some modifications, that delay could be avoided?
>
>~Kunal
>
>
>
>
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>trial. Simplify your report design, integration and deployment - and focus on 
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Xlightweb-develop mailing list
>Xli...@li...
>https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>


      

Re: [Xlightweb-develop] Delay in sendInternal

[<gre...@go...>]

[Xlightweb-develop] Delay in sendInternal

[Kunal E. <kun...@ya...>]

Hi,

I observe a delay of 5 seconds (constant) everytime the send function of HttpClientConnection(non_blocking_connection) is invoked.


[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|Got a non blockconnection|#]
[#|2009-11-24T13:12:19.495+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppClient|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;|About to FWD the GET request|#]
[#|2009-11-24T13:12:19.508+0530|INFO|sun-glassfish-comms-server2.0|proxy.http.HttpAppConnHandler|_ThreadID=32;_ThreadName=xNbcPool-1-thread-9;|Connect successful|#]
[#|2009-11-24T13:12:24.103+0530|FINE|sun-glassfish-comms-server2.0|org.xlightweb.client.HttpClientConnection|_ThreadID=18;_ThreadName=httpWorkerThread-8080-0;ClassName=org.xlightweb.client.HttpClientConnection;MethodName=sendInternal;_RequestID=f74c2770-e824-4b41-bbba-dbdca71aecc6;|[3279534412524e787771611293eCaI0] sending (bodyless): GET /index HTTP/1.1Host: 10.3.3.99:80 User-Agent: xLightweb/2.9.1


The only suspicion i see is in addMessageHeaderHandler:

private void sendInternal(IHttpRequest request, IHttpResponseHandler responseHandler) throws IOException, ConnectException {
       addMessageHeaderHandler(new MessageHeaderHandler(new ResponseHandlerAdapter(responseHandler, request.getRequestHeader()), request.getRequestHeader(), responseTimeoutMillis));
        
       ........
}

At application I have (excerpt without error handling):
pool = new NonBlockingConnectionPool();
nbc = pool.getNonBlockingConnection(host, port, new Handler());
con = new HttpClientConnection(nbc); 
con.send(request, null);

My question is whether it is expected delay or doing some modifications, that delay could be avoided?

 ~Kunal



      

Re: [Xlightweb-develop] xlightweb - Disconnection after sending 4xx response

[Sorawit W. <SWa...@vi...>]

Dear Gregor,

Thank you very much for your support.
Regarding the onDisconnect method, do you mean the method is called if the connection is disconnected anyhow?


Best Regards,
Sorawit Wanitwarodom

From: Gregor Roth [mailto:gre...@gm...]
Sent: Friday, November 06, 2009 9:26 PM
To: Sorawit Wanitwarodom
Cc: xli...@li...
Subject: Re: xlightweb - Disconnection after sending 4xx response


Hi,

the xLightweb client will only close the connection (in case of keep-alive) if a 5xx response is received. This is not true for a 4xx response. The next version of xLightweb supports a SystemProperty org.xlightweb.client.closeConnectionOn5xxResponse to control this behaviour.

The xlightweb server will close the connection, if a 4xx or a 5xx response is written. This will be changed with the next version. Than per default the connection is only close in case of 5xx. Also a new property org.xlightweb.server.closeConnectionOn5xxResponse is added. Further more the HttpServer class supports a setCloseOnSendingError() metod by setting true (default will be changed to false) the connection will be closed in case of 4xx and 5xx



The onDisconnect is called independent of the originator (client, server)



Gregor









----- Original Message -----

From: Sorawit Wanitwarodom

Sent: 11/06/09 07:04 am

To: Gregor Roth

Subject: xlightweb - Disconnection after sending 4xx response


Dear Gregor,


Thank you very much for your assistance with the Handler issue last time.
There are more issues about the connection that we need your suggestion.


We have noticed that whenever the server sends 4xx response to a client,  the connection is lost even if we set it to keep-alive.
Is this behavior normal or is it intentionally designed to work that way in the xlightweb framework?
Is the disconnection occurs on the server side (the server disconnects the connection),
or does the client disconnect when it receives 4xx response,
or does the server send a reset packet to the client after it sends 4xx and the client tries to send more request?
We would really appreciate if you could provide us some resources regarding this issue.


Related to the question above, which scenario triggers the IHttpDisconnectHandler.onDisconnect() method?
Is it only triggered if a client disconnects itself, or the server disconnects the connection, or a connection somehow disconnects (e.g. a cable is unplugged)?


Thank you very much.




Best Regards,
Sorawit Wanitwarodom

Re: [Xlightweb-develop] xlightweb - Disconnection after sending 4xx response

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] xlightweb - Disconnection after sending 4xx response

[Sorawit W. <SWa...@vi...>]

Dear Gregor,

Thank you very much for your assistance with the Handler issue last time.
There are more issues about the connection that we need your suggestion.

We have noticed that whenever the server sends 4xx response to a client,  the connection is lost even if we set it to keep-alive.
Is this behavior normal or is it intentionally designed to work that way in the xlightweb framework?
Is the disconnection occurs on the server side (the server disconnects the connection),
or does the client disconnect when it receives 4xx response,
or does the server send a reset packet to the client after it sends 4xx and the client tries to send more request?
We would really appreciate if you could provide us some resources regarding this issue.

Related to the question above, which scenario triggers the IHttpDisconnectHandler.onDisconnect() method?
Is it only triggered if a client disconnects itself, or the server disconnects the connection, or a connection somehow disconnects (e.g. a cable is unplugged)?

Thank you very much.


Best Regards,
Sorawit Wanitwarodom

Re: [Xlightweb-develop] application level load balancer question

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] application level load balancer question

[Ron K. <ron...@gm...>]

Hi, Gregor,

I've been reading the Javaworld article about load balancers, and I have a
question
about the examples in the article.

What is supposed to happen in a real production type balancer where you say

// proxy header handling ( remove hop-by-hop headers,...)

Also, I want to set the redirect option to true in my httpclient, will this
be okay?

How many concurrent connections do you think these example balancers
can handle on a fast machine?

Thanks,

Ron

Re: [Xlightweb-develop] Many Connections to Server

[ณพ สุว. <hel...@wi...>]

 Hi Gregor,

      

          I am very new to this areas. 

          Can you provide some refferences about this?

          I used to simulate test by using JMeter before but got about file discriptor 

thing and I fixed by adding more number on linux machine.   

 

         This result about   "java.net.SocketException: socket closed" which I tested on windows.

Do you have any suggestions about using too many connections things??


 

Thanks so much for your time.

Aun.

    


CC: xli...@li...
Date: Thu, 8 Oct 2009 08:44:29 +0200
From: gre...@gm...
Subject: Re: Many Connections to Server
To: hel...@wi...





Hi,




do you know if persistent HTTP connections will be used (it depends also on the request). 





May this is a too many file handles issue, which means too many connections will be opened and closed within a very small period of time. In this case some OS specific-parameters has to be modified, to allow more file handles.



Gregor 








----- Original Message -----

From: ณพ สุวพรหม

Sent: 10/08/09 06:50 am

To: gre...@gm..., xli...@li...

Subject: Many Connections to Server

 



�Hi ,


� � �Please help, I have some question on ...


� � �IServer server = new HttpServer(address, PORT, ConnectionHandler);
�
� � �1. �When I have many connection I got the following message, What should I do?


java.net.SocketException: socket closed
at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at org.apache.jmeter.protocol.http.sampler.HTTPSampler.readResponse(HTTPSampler.java:





� 2.�� Is this related to No.1 ? server.setWorkerpool(Executors.newFixedThreadPool(POOL_SIZE));
� � � � Do I have to setWorkerPool and what is the different ?
� �

� � � �


Thanks so much,
Aun.



แชตออนไลน์ทันใจกับเพื่อนและครอบครัวของคุณ! Windows Live Messenger 


 


 		 	   		  
_________________________________________________________________
Windows Live: ให้ข้อมูลอัปเดตสำหรับเพื่อนของคุณเกี่ยวกับสิ่งที่คุณทำบนโลกออนไลน์
http://www.microsoft.com/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:th-th:SI_SB_1:092010

Re: [Xlightweb-develop] Many Connections to Server

[Gregor R. <gre...@gm...>]

[Xlightweb-develop] Many Connections to Server

[ณพ สุว. <hel...@wi...>]

�Hi ,


� � �Please help, I have some question on ...


� � �IServer server = new HttpServer(address, PORT, ConnectionHandler);
�
� � �1. �When I have many connection I got the following message, What should I do?


java.net.SocketException: socket closed
	at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at java.net.HttpURLConnection.getResponseCode(Unknown Source)
	at org.apache.jmeter.protocol.http.sampler.HTTPSampler.readResponse(HTTPSampler.java:





� 2.��		Is this related to No.1 ? server.setWorkerpool(Executors.newFixedThreadPool(POOL_SIZE));
� � � � Do I have to setWorkerPool and what is the different ?
�	�

� � � �


Thanks so much,
Aun.
 		 	   		  
_________________________________________________________________
Windows Live Hotmail: เพื่อนของคุณได้รับรู้การอัปเดต Facebook ของคุณได้ทันทีจาก Hotmail®
http://www.microsoft.com/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:th-th:SI_SB_4:092009

Re: [Xlightweb-develop] HttpClient persisting connections

[Tony P. <ton...@wa...>]

Hi Gregor,

Furthermore, when the program exits, it usually takes a while after the 
main() method has completed before it properly terminates.

I suspect that it is some of the threads in the cached thread pool of 
the http client that is causing this.  Again, a method to properly 
shutdown connections once they are done would presumably solve this.  I 
am calling HttpClient.close(), but that doesn't seem to be solving the 
problem.

My use case is I want a super-fast single-threaded client, that only 
ever sends the same message to the same server, and waits for the 
response.  I am aiming to do this once every 50 milliseconds.  Ideally 
it would be able to reuse the previous http clients connection to the 
same server, rather than starting up a new connection in a new thread.  
The main reason I am using xlightweb is for the SSL support.

Any pointers on how I can achieve this are much appreciated.

Thanks,
Tony

Tony Poppleton wrote:
> Hi Gregor,
>
> I am using the latest version of xlightweb 2.8.5, in conjunction with 
> xSocket 2.6.4, all running on Java 1.6.
>
> Thanks,
> Tony
>
> Gregor Roth wrote:
>>
>> Hello Tony,
>>
>>
>> which Version of xlightweb do you use?
>>
>>
>> Gregor
>>
>>
>>
>>> ----- Original Message -----
>>>
>>> From: Tony Poppleton
>>>
>>> Sent: 10/07/09 06:54 am
>>>
>>> To: xli...@li...
>>>
>>> Subject: [Xlightweb-develop] HttpClient persisting connections
>>>
>>>  
>>>
>>> Hello,
>>>
>>> I am using HttpClient (with SSL) and it appears to be inefficiently
>>> persisting resources. When I run a profiler, it shows that a new thread
>>> is being created each time I send out a request, rather than just
>>> reusing an old one. More importantly however, it appears to not be
>>> closing down connections (as evidenced by running netstat on the 
>>> Windows
>>> command prompt).
>>>
>>> This persisting connections problem becomes apparent when I set
>>> client.setMaxActive(1), after which it throws the following exception
>>> the second time I client.call(...)
>>>
>>> Exception in thread "main"
>>> org.xsocket.connection.MaxConnectionsExceededException: max active
>>> connections 2 exceeded
>>> at
>>> org.xsocket.connection.NonBlockingConnectionPool.getConnection(NonBlockingConnectionPool.java:526)
>>> at
>>> org.xsocket.connection.NonBlockingConnectionPool.getNonBlockingConnection(NonBlockingConnectionPool.java:265)
>>> at
>>> org.xlightweb.client.HttpClientConnectionPool.getHttpClientConnection(HttpClientConnectionPool.java:169)
>>> at
>>> org.xlightweb.client.HttpClientConnection$ClientExchange.forward(HttpClientConnection.java:1373)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:401)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:489)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:475)
>>> at org.xlightweb.client.RetryHandler.onRequest(RetryHandler.java:145)
>>> at
>>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.performRequestHandler(AbstractHttpConnection.java:2067)
>>> at
>>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.onRequest(AbstractHttpConnection.java:2050)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:392)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:489)
>>> at
>>> org.xlightweb.client.RedirectHandler.onRequest(RedirectHandler.java:82)
>>> at
>>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.performRequestHandler(AbstractHttpConnection.java:2067)
>>> at
>>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.onRequest(AbstractHttpConnection.java:2050)
>>> at
>>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:388)
>>> at
>>> org.xlightweb.RequestHandlerChain.onRequest(RequestHandlerChain.java:260)
>>> at org.xlightweb.client.HttpClient.send(HttpClient.java:1069)
>>> at org.xlightweb.client.HttpClient.send(HttpClient.java:1051)
>>> at org.xlightweb.client.HttpClient.call(HttpClient.java:1037)
>>>
>>> I am doing multiple call(...) calls on the same client, and I have no
>>> need for ever doing them in parallel (all calls are from the same
>>> thread). Do I need to be calling a method after each client.call(...)
>>> to close down the connection that was just made?
>>>
>>> I am reading the response using the blocking response.getBlockingBody()
>>> method, which has a close() defined. However calling this doesn't seem
>>> to change anything.
>>>
>>> Many thanks,
>>> Tony
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and 
>>> stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Xlightweb-develop mailing list
>>> Xli...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>>
>>  
>>
>>
>> ---------------------------------------------------------------------------------------
>> Orange vous informe que cet e-mail a été contrôlé par l'anti-virus mail.
>> Aucun virus connu à ce jour par nos services n'a été détecté.
>>
>>
>
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a été contrôlé par l'anti-virus mail.
> Aucun virus connu à ce jour par nos services n'a été détecté.
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xlightweb-develop mailing list
> Xli...@li...
> https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>   

Re: [Xlightweb-develop] HttpClient persisting connections

[Tony P. <ton...@wa...>]

Hi Gregor,

I am using the latest version of xlightweb 2.8.5, in conjunction with 
xSocket 2.6.4, all running on Java 1.6.

Thanks,
Tony

Gregor Roth wrote:
>
> Hello Tony,
>
>
> which Version of xlightweb do you use?
>
>
> Gregor
>
>
>
>> ----- Original Message -----
>>
>> From: Tony Poppleton
>>
>> Sent: 10/07/09 06:54 am
>>
>> To: xli...@li...
>>
>> Subject: [Xlightweb-develop] HttpClient persisting connections
>>
>>  
>>
>> Hello,
>>
>> I am using HttpClient (with SSL) and it appears to be inefficiently
>> persisting resources. When I run a profiler, it shows that a new thread
>> is being created each time I send out a request, rather than just
>> reusing an old one. More importantly however, it appears to not be
>> closing down connections (as evidenced by running netstat on the Windows
>> command prompt).
>>
>> This persisting connections problem becomes apparent when I set
>> client.setMaxActive(1), after which it throws the following exception
>> the second time I client.call(...)
>>
>> Exception in thread "main"
>> org.xsocket.connection.MaxConnectionsExceededException: max active
>> connections 2 exceeded
>> at
>> org.xsocket.connection.NonBlockingConnectionPool.getConnection(NonBlockingConnectionPool.java:526)
>> at
>> org.xsocket.connection.NonBlockingConnectionPool.getNonBlockingConnection(NonBlockingConnectionPool.java:265)
>> at
>> org.xlightweb.client.HttpClientConnectionPool.getHttpClientConnection(HttpClientConnectionPool.java:169)
>> at
>> org.xlightweb.client.HttpClientConnection$ClientExchange.forward(HttpClientConnection.java:1373)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:401)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:489)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:475)
>> at org.xlightweb.client.RetryHandler.onRequest(RetryHandler.java:145)
>> at
>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.performRequestHandler(AbstractHttpConnection.java:2067)
>> at
>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.onRequest(AbstractHttpConnection.java:2050)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:392)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.forward(RequestHandlerChain.java:489)
>> at
>> org.xlightweb.client.RedirectHandler.onRequest(RedirectHandler.java:82)
>> at
>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.performRequestHandler(AbstractHttpConnection.java:2067)
>> at
>> org.xlightweb.AbstractHttpConnection$RequestHandlerAdapter.onRequest(AbstractHttpConnection.java:2050)
>> at
>> org.xlightweb.RequestHandlerChain$ChainExchange.handle(RequestHandlerChain.java:388)
>> at
>> org.xlightweb.RequestHandlerChain.onRequest(RequestHandlerChain.java:260)
>> at org.xlightweb.client.HttpClient.send(HttpClient.java:1069)
>> at org.xlightweb.client.HttpClient.send(HttpClient.java:1051)
>> at org.xlightweb.client.HttpClient.call(HttpClient.java:1037)
>>
>> I am doing multiple call(...) calls on the same client, and I have no
>> need for ever doing them in parallel (all calls are from the same
>> thread). Do I need to be calling a method after each client.call(...)
>> to close down the connection that was just made?
>>
>> I am reading the response using the blocking response.getBlockingBody()
>> method, which has a close() defined. However calling this doesn't seem
>> to change anything.
>>
>> Many thanks,
>> Tony
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and 
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Xlightweb-develop mailing list
>> Xli...@li...
>> https://lists.sourceforge.net/lists/listinfo/xlightweb-develop
>
>  
>
>
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a été contrôlé par l'anti-virus mail.
> Aucun virus connu à ce jour par nos services n'a été détecté.
>
>

Re: [Xlightweb-develop] HttpClient persisting connections

[Gregor R. <gre...@gm...>]