Two way long running servlet connection problem

[Paritosh Patel <to...@ocpinc.net>]

I apologize if this question has been asked before, but I could not find the
question in this list.

My client makes what I call long running servlet request. By that what I
mean is that the client makes a servlet request and the server keeps the
ServletOutputStream open for a long time. I use this connection so that the
server can send periodic data down to the client. This has been working
quite well. I did not need for the client to send additional data after the
initial servlet request so I was closing its output stream after I made the
request and the servlet did not use its corresponding ServletInputStream.
Any new data from the client to the server was sent over a new "short"
servlet request.

Now I have the need for the client to send some additional data to the
server, and I would really prefer to send the data over the same connection
to the long running servlet. I changed my request code to keep the output
stream open and send data over it. I get no error doing this. But on the
server side, the long running servlet tries to read the ServletInputStream
and it does not get any data.

What am I doing wrong? Is this not supported?

Sincerely,
Tosh

Re: Two way long running servlet connection problem

[Paritosh Patel <to...@ocpinc.net>]

OK. I understand. Thank you very much for your help. I will look into WebDAV
and Comet.

Sincerely, Tosh

On Sun, Nov 21, 2010 at 3:37 PM, Mark Thomas <ma...@apache.org> wrote:

> On 21/11/2010 13:24, Paritosh Patel wrote:
> > What am I doing wrong?
>
> You are trying to get the HTTP protocol to do something it was never
> intended to support.
>
> > Is this not supported?
>
> Yes, this is not supported.
>
> Use Comet.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Sincerely,
Paritosh

Re: Two way long running servlet connection problem

[Mark Thomas <ma...@apache.org>]

On 21/11/2010 13:24, Paritosh Patel wrote:
> What am I doing wrong?

You are trying to get the HTTP protocol to do something it was never
intended to support.

> Is this not supported?

Yes, this is not supported.

Use Comet.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Two way long running servlet connection problem

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: xygnusx1@gmail.com [mailto:xygnusx1@gmail.com] On Behalf Of Paritosh Patel
> Subject: Re: Two way long running servlet connection problem

> I hope this makes it more clear.

Pretty much what I thought you were doing.

> Should I be doing something explicitly to keep the 
> connection alive or does the connection close after
> some inactivity on its own?

Again, don't confuse the TCP /connection/ with the HTTP /conversation/.  The TCP connection will stay open by default, but the client-to-server side of the conversation is considered done when the client sends a complete HTTP request.  If you really want to piggy back your proprietary data on top of an HTTP request, you'll need to make sure chunked-encoding is set, and mimic the behavior of some streaming mechanism, such as a file transfer.  Look at WebDAV or similar to see how that's done.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Two way long running servlet connection problem

[Paritosh Patel <to...@ocpinc.net>]

Sorry about that. Here is the system description:

Platform: Intel/Mac, Intel Linux, Windows 32bit. All 3 platforms have the
same Tomcat/Java as below.
Tomcat 6.0.26 (no web server installed)
Sun Java:  1.6.0.22

Let me try to describe the code flow a bit more so that it may give a better
understanding of the "connection" between my client and server.

First of all, I did it this way because if I used a different port I could
have opened a socket connection to do my bi-directional communication. Using
port 80 means I have less issues about firewalls. So the flow is as follows:

1) the client worker thread make a servlet request, opens the input stream
to get the servlet response. After the servlet response is received, the
input stream is kept open. From now on the thread periodically checks the
input stream for data and processes it.
2) On the web app side, the servlet gets the request, sends back the
response, but then does not close the output stream. Instead, it does other
work and periodically sends more data (binary data) on the output stream. I
do not do anything special for the "keep-alive".

Notice that so far, this is a one-way (server down to client) flow. What I
want to do is to have two-way communication over a long time. So, the
modified code works like this:

1) the client worker thread makes the servlet request as usual on its output
stream, but then keep that stream open, to later send additional data to the
server. This data is not a servlet request but binary data of my own format.
 The input stream is opened to get the servlet response and to receive
additional other binary data in the future.
2) On the web side, the servlet keeps open the input and output streams,
sends a servlet response and then later sends binary data to the client as
necessary. But now, since it has also kept open the input stream it should
receive the binary data from the client... at least that was my expectation.
Instead, I do not get any data (<stream>.available() always returns 0).

I hope this makes it more clear.

Based on some of the responses, I have an additional question:
1) Should I be doing something explicitly to keep the connection alive or
does the connection close after some inactivity on its own?

Thank you all of looking at my problem.

Sincerely,
- Tosh

Re: Two way long running servlet connection problem

[André Warnier <aw...@ice-sa.com>]

Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@ice-sa.com] 
>> Subject: Re: Two way long running servlet connection problem
> 
>> In HTTP 1.1, a change was made, with the objective of 
>> avoiding the overhead of establishing/destroying a 
>> connection for each request.
> 
> Careful here.  The "connection" described above is the underlying TCP connection, not the HTTP conversation.
> 
>> The server reads an processes the request, and sends the response.
>> The client can now send a second request on the same connection.
> 
> The scenario the OP wants to discuss is not the simple request/response situation, but more akin to a streaming mechanism, such as a file transfer - but in this case, bidirectional.  There's nothing in HTTP that prevents that, as long as appropriate headers are generated so that both the request and response do not have pre-established lengths.
> 
>> Basically what I mean, is that there is not really a 
>> provision in the webapp logic, for processing a second
>> request after it has sent a response to the current one.
> 
> Don't think of it as a second request, but rather as a continuation of the existing one - again, similar to a file transfer over HTTP.
> 
I am not saying that it is not possible, I am saying that this is not really "classic" 
HTTP anymore.
You are probably thinking of chunked encoding, but in my view that is quite a different 
thing : the kind of "conversation" going on there is no longer at the application level, 
and it concerns purely "housekeeping" in terms of "here is another block of nnn bytes". 
There is not really any "intelligent" conversation going on there.

To do what the OP seems to want, the client would have to send an "incomplete" request, 
the webapp would have to start processing it despite the fact that it is incomplete; it 
would have to send an incomplete response, to which the client would have to react by 
sending another chunk of request, and so on.  I just believe that this would be a lot of 
trouble to achieve given the standard tools and APIs, and I wonder if the end justifies 
the trouble.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Two way long running servlet connection problem

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: André Warnier [mailto:aw@ice-sa.com] 
> Subject: Re: Two way long running servlet connection problem

> In HTTP 1.1, a change was made, with the objective of 
> avoiding the overhead of establishing/destroying a 
> connection for each request.

Careful here.  The "connection" described above is the underlying TCP connection, not the HTTP conversation.

> The server reads an processes the request, and sends the response.
> The client can now send a second request on the same connection.

The scenario the OP wants to discuss is not the simple request/response situation, but more akin to a streaming mechanism, such as a file transfer - but in this case, bidirectional.  There's nothing in HTTP that prevents that, as long as appropriate headers are generated so that both the request and response do not have pre-established lengths.

> Basically what I mean, is that there is not really a 
> provision in the webapp logic, for processing a second
> request after it has sent a response to the current one.

Don't think of it as a second request, but rather as a continuation of the existing one - again, similar to a file transfer over HTTP.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Two way long running servlet connection problem

[André Warnier <aw...@ice-sa.com>]

Caldarale, Charles R wrote:
>> From: xygnusx1@gmail.com [mailto:xygnusx1@gmail.com] On Behalf Of Paritosh Patel
>> Subject: Two way long running servlet connection problem
> 
>> What am I doing wrong?
> 
> For starters, you're not telling us the version of Tomcat in use, the JVM level it's running in, the platform you're running on, and whether or not Tomcat is front-ended by any web server, such as httpd or IIS.
> 
Apart from the above, I will put on my RFC hat, and muse a bit about the general idea.

In HTTP 1.0, the basic scheme was :
- a client establishes a connection with the webserver, and sends a request over this 
connection. It then waits for the answer on the same connection.
- the server receives the request, processes it, sends a response over the connection.
- the client reads the response
- the connection is closed
Repeat for the next request.

In HTTP 1.1, a change was made, with the objective of avoiding the overhead of 
establishing/destroying a connection for each request.
A client can establish a connection with the webserver, and request that this connection 
be "persistent" (keep-alive).
It then sends a first request on the connection.
The server reads an processes the request, and sends the response.
The client can now send a second request on the same connection.
Repeat.
If the client sends no more requests on the connection, after a suitable timeout, the 
server closes the connection.

Now in all that it does not, to my knowledge, specify that on the server side, it will be 
the same process which handles all the requests on the same connection.
So maybe your idea of re-using the connection, with the hope of reaching the same 
"process" on the server side, is not really guaranteed to work.

Basically what I mean, is that there is not really a provision in the webapp logic, for 
processing a second request after it has sent a response to the current one.

In other words, you current scheme seems the right one.  Just use a persistent connection, 
and the rest will take care of itself.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Two way long running servlet connection problem

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: xygnusx1@gmail.com [mailto:xygnusx1@gmail.com] On Behalf Of Paritosh Patel
> Subject: Two way long running servlet connection problem

> What am I doing wrong?

For starters, you're not telling us the version of Tomcat in use, the JVM level it's running in, the platform you're running on, and whether or not Tomcat is front-ended by any web server, such as httpd or IIS.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org