Hi Marc,
just couple of question to understand your usecase better...
Correct me if I'm wrong, what you're planning to do on Apache side is
distinguish clients by request URLs, and depending on them you will
apply or not 100s timeout on Apache.
Now (as I understand) the issue you see is that Grizzly also has
keep-alive- and request- timeouts, which similarly to Apache closes idle
connections. So you'd like to disable these timeouts (for specific
clients) on Grizzly side as well.
Is that correct?
Thanks.
WBR,
Alexey.
On 06/25/2012 03:53 PM, Arens, Marc wrote:
> Hello,
>
> we are currently evaluating Grizzly as servlet container replacement for our
> Open-Xchange server. In our usecase-scenario we set up several
> Open-Xchange/Grizzly backends behind an Apache balancer and connect those with
> mod_proxy_balancer and mod_proxy_http. The balancer is configured with a timeout
> [1] (Connection timeout in seconds. The number of seconds Apache waits for data
> sent by / to the backend.) of 100 seconds. Request routing is done via special
> JSessionIds with appended backend routes. The communication with some of our
> possible clients is realized via server push from servlets, the client opens a
> connection and waits for for the next data to receive from the server. We have
> to be able to keep the connections to those special clients alive for an
> undefined time interval while the rest of the clients will be affected by the
> 100s timeout. Those special clients can simply be identified by the request url.
> Now i'm looking for the best way to keep the connection between backend and
> balancer alive without rewriting everything to use websockets.
>
> I thought about writing a filter to watch writes on those connections based on
> request url and implement something like a watcher thread that periodically
> checks the last read/write times and sends a keep-alive package to the balancer
> if needed. But i don't know if Grizzly let's me safely access the
> response/connection while another thread from the backend might access the same
> response/connection anytime to do another message push. Do you have any ideas or
> pointers for further research? Another question is how to build the package so
> it just keeps the connection between backend and balancer alive and doesn't even
> reach the client?
>
> [1] http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxytimeout
>
> Best regards
> --
> Marc Arens
> Backend Development
> Open-Xchange AG
>
> Phone: +49 2761 8385-0, Fax: +49 2761 838530
>
> -------------------------------------------------------------------------------
> Open-Xchange AG, Rollnerstr. 14, 90408 Nürnberg, Amtsgericht Nürnberg HRB 24738
> Vorstand: Rafael Laguna de la Vera, Carsten Dirks, Aufsichtsratsvorsitzender:
> Richard Seibt
>
> European Office: Open-Xchange GmbH, Martinstr. 41, D-57462 Olpe, Germany
> Amtsgericht Siegen, HRB 8718, Geschäftsführer: Frank Hoberg, Martin Kauss
>
> US Office: Open-Xchange, Inc., 303 South Broadway, Tarrytown, New York 10591
> -------------------------------------------------------------------------------