Murat,
   I've been using a remoting framework which I initially created based
   on mina, with the purpose of using http to create a persistent
   bidirectional connection when NAT/Firewall prevents persistent TCP
   connections.  During this endevour, I encountered the same problems
   as you with the HTTP connections being closed, but often you don't
   see this behavior until you go through a proxy server which almost
   always will close the connection after the response is received. 
   Almost all web servers today support HTTP 1.1 and keep-alive, but
   although proxy servers ussually support 1.1, they still add the
   "connection: close" header to the response because they can't afford
   to keep the connection open to the client, because to do so means
   they also have to keep it open to the server and this does not scale
   well (not using blocking sockets anyway).  There may be a proxy
   server which doesn't do this, but I haven't seen one.  Bottom line is
   that you have to live with the connection closing after every
   response in order to support common http usage today (proxy servers). 

In my case the solution was to create an additional layer of abstraction
on top of the SocketSession which I called my HttpChannel.  The
HttpChannel actually contains two SocketSessions which work together to
create one "ChannelSession" which appears to never be disconnected, and
is where I locate the filters such as SSL so that they don't have to be
reestablished after every SocketSession disconnection.  The way it works
from the client side, is that you have one SocketSession used to PUSH
data to the server, then when the server receives the data it knows it's
a PUSH request and must return a response immediately, and will bundle a
few queued messages in the http response destined for the client as well
(if any).  The other SocketSession is the PULL session, which is how the
server is able to send data to the client at anytime. The client sends
an http request (even if empty) to the server, and the server see's that
it is a PULL request so it does not send a response, until it has data
to send to the client, or the connection is closed due to timeout. 
Because the response is not sent, the client and any proxy servers will
hold the sockets open.  If the connection is closed it is immediately
reestablished.   Using this combination of PUSH and PULL SocketSessions
managed inside the HttpChannel, a single virtual bidirectional "channel"
is maintained between a client and server, even with proxy servers
inbetween closing connections all the time.  Works great.

So, moral of the story is try to make your solution work supporting http
1.0.  Even if you use chunked encoding, you have to watch out for Proxy
servers which are also doing Anti-Virus checks, because they will often
buffer the entire chuncked encoding so that they can perform the virus
scan on the complete message, which negates the purpose of chunked
encoding.

Ok enough already, someone pry my hands off this keyboard...!

Lee Carlson

----- Original message -----
From: "Murat OZDEMiR" <[EMAIL PROTECTED]>
To: [email protected]
Date: Wed, 28 Mar 2007 11:04:30 +0300
Subject: RE: SocketConnector Closes Session at 20 sec.

Thank you very much Niklas,

I guess you're right. Using HTTP/1.0 i'm receiving expected response but
connection is closed.
****************************************************************************
****************************************************************************
****
REQUEST

GET /DEKA-SMSCServlet?cmd=REGISTER&pPwd=xxxxx&pUser=YYYYYYY& HTTP/1.0
Connection : Keep-Alive
Host : elcosis.com:8585
Accept-Language : tr
Content-Type : application/x-www-form-urlencoded
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
RESPONSE

HTTP/1.1 200 OK
Content-Length: 277
Date: Wed, 28 Mar 2007 07:59:06 GMT
Server: Apache-Coyote/1.1
Connection: close

cmd=REGISTER&pUser=&pPwd=&pSessionId=200703281059069550&pRetCode=200&pServic
e_Code=5141&pSubService_Code=&pMsisdn=&pDstMsisdn=&pContent=&pContentId=&pMu
ltiplier=&pSend_Date=&pDelete_Date=&pXser=&pNreq=&pMsgId=&pStatus=&pSender=&
pSrvSNCode=&pId=&pSourceMsisdn=&pErrCode=0&pRpid=


I've tried HTTP/1.1 one but i've received HTTP/1.1 400 Bad Request. Do
you
know why?

****************************************************************************
****************************************************************************
****
REQUEST

GET /DEKA-SMSCServlet?cmd=REGISTER&pPwd=xxxxx&pUser=YYYYYYY& HTTP/1.1
Connection : Keep-Alive
Host : elcosis.com:8585
Accept-Language : tr
Content-Type : application/x-www-form-urlencoded

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
RESPONSE

HTTP/1.1 400 Bad Request
Transfer-Encoding: chunked
Date: Wed, 28 Mar 2007 07:50:26 GMT
Server: Apache-Coyote/1.1
Connection: close

0
 
****************************************************************************
****************************************************************************
****

----------
Murat OZDEMIR

-----Original Message-----
From: Niklas Therning [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 28, 2007 10:44 AM
To: [email protected]
Subject: Re: SocketConnector Closes Session at 20 sec.

Well AFAIK that's the normal behaviour in HTTP 1.0, the client connects,
sends an HTTP request, gets a response and the server closes the
connection.
You need to be using HTTP 1.1 and specify in the HTTP request that the
connection should be kept alive I think (using the header Connection:
keep-alive).

/Niklas

Murat OZDEMiR wrote:
>  
> I've now tested using other simple TCP client utility, and faced that 
> one of them is closing connection after around 20 seconds but the 
> other is not. The problem is when i send a http request, the 
> connection/session is closed as soon as response is received.
> I should find out why.
> Any comments?
>
> ----------
> Murat OZDEMIR
>
> -----Original Message-----
> From: Murat OZDEMiR [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 28, 2007 10:33 AM
> To: '[email protected]'
> Subject: RE: SocketConnector Closes Session at 20 sec.
>
> First is "Apache-Coyote/1.1" which belongs to us and second is
> "Apache/1.3.37 (Unix)" which belongs o GSM operator smsc http server.
>
> ----------
> Murat OZDEMIR
>
> -----Original Message-----
> From: Niklas Therning [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 28, 2007 10:09 AM
> To: [email protected]
> Subject: Re: SocketConnector Closes Session at 20 sec.
>
> What server are you connecting to? Could it be that the server closes 
> idle connections after 20 seconds of idleness?
>
> /Niklas
>
> Murat OZDEMiR wrote:
>   
>> Latest news about " SocketConnector Closes Session at 20 sec."
>>
>> I have a poller method which is executed at every 20 seconds by a 
>> timer schedule. So i see that the socket is closed after 20 seconds.
>> But i guess that session is closed whenever a http response received 
>> from
>>     
> web server.
>   
>> You can find an image attached. A thread named 
>> "SocketConnectorIoProcessor-0.0" is somehow closed. I don't know why.
>> Any comments?
>>
>> ----------
>> Murat OZDEMIR
>>
>> -----Original Message-----
>> From: Trustin Lee [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, March 28, 2007 5:40 AM
>> To: [email protected]
>> Subject: Re: SocketConnector Closes Session at 20 sec.
>>
>> Hi Murat,
>>
>> On 3/27/07, Murat Ozdemir <[EMAIL PROTECTED]> wrote:
>>   
>>     
>>> Hi all,
>>> SocketConnector closes Session at 20 sec. when idle. But i have set 
>>> the worker timeout to 100 sec.
>>>
>>> Despite
>>>     // worker timeout to 100 second to make the I/O thread quit soon
>>>     connector.setWorkerTimeout( 100 );
>>>     
>>>       
>> I/O processor will never quit if there's any connected session.  The 
>> worker timeout is applied only when there's no connected.  Therefore, 
>> you don't need to adjust this property at all.
>>
>>   
>>     
>>> and
>>>     // HTTP_CONNECT_TIMEOUT = 10 sec.
>>>     cfg.setConnectTimeout(
>>> SmsCenterConstants.HTTP_CONNECT_TIMEOUT );
>>>     
>>>       
>> The connect timeout is applied only for a connection attempt.  If the 
>> session is already connected and created, this property doesn't 
>> affect the session at all.
>>
>> I suspect that you set idle time to 20 seconds, or the client is 
>> configured to close the connection when it's idle for 20 seconds.  
>> The code will look like this for example:
>>
>> session.setIdleTime(IdleStatus.BOTH_IDLE, 20);
>>
>> HTH,
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>   
>>     
>
>
>
>   


--
Niklas Therning
www.spamdrain.net

Reply via email to