[EMAIL PROTECTED] wrote:
Please, I need Advice for connections
Hi guys.
I need a technical advice using tomcat 5.0
Presently, tomcat server is used with JBOSS in a solution that
I am developping for my clients.
Users are connecting to the solution by invoking a servlet (runned by tomcat).
If a user is auhentified, then I use HTTPServletResponse object (in the service
method) to get the Outputstream of that object =>
HTTPServletResponse.getoutputstream)
Then this stream will be use to handle communications between my client
application
and my custom Server Process (I need to send real time informations through
this canal).
Then you're messing it up. HTTP has no paradigm of a session, which is
what you need here. HTTP has a very clear request/response model. It is
not designed to hold the HTTP channel open indefinitely and will break
off after a timeout. Timeout is configurable both on client and server
sides. So, you can easily get server timeout or client timeout on the
connection. And that is definitely not good for a realtime application :-)
Even if you consider using HTTP/1.1 and Keep-Alive option, it will not
help you, since it holds the TCP channel open, but request and rsponse
may still timeout.
Important => A client session can last several hours, so the life of the
servlet is set to time infinite.
Then you're definitely looking for some session oriented protocol, be it
your own or something existing, like SSH (not your case), a generic SSL
channel (if you need encryption) or something you build.
In fact I had the idea delegate socket connection managment, to tomcat engine,
by setting servlet life time to infinite.
Is it a good way to do, or should I use a socket pooling algorithm (actualy,
the server can freeze, after unregular amout of times, time for writing
operation
in the Output stream can increase until being totaly unusuable, I have to
close, and reconnect)
The objective is to handle more than 1000 client sessions.
Please, i need a quick answer .
Thank you for your help.
Use servlets what they are intended for, please. Even if you succeed,
somehow, you'll be writing most of the low-level code anyway, so why not
go for a clean solution - one that you can control and configure yourself.
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
