[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Continuation and streaming
|
Do you mean that an network equipment between the server and the client can interfere with the connection because it will be open a long time ?
Should I use a pattern like open -> send -> close ?
I will check websocket, but from what I understand it will open an connection that I can use as a duplex connection (we can't do that with HTTP). Why this kind of connection will less suffer from network equipment ?
I will also have a look at cometD, but for the moment the client just have to open a connection and the server send messages without the user needs to request to listen to a topic.
Thanks.
William.
On Mon, Jun 13, 2011 at 9:59 PM, Simone Bordet
<sbordet@xxxxxxxxxxx> wrote:
Hi,
> Hi jetty users!
>
> I'd like to make a http comet streaming server with Jetty 7, for that I've looked at the documentation
> and for my test case I should use the "Suspend Continue Pattern".
>
> In my understanding, I should keep the continuation object (that contains the response) and write in it
> each time I have a message to send and I should also never resume or complete the connection.
>
> Is it a pattern that you encourage to use ?
No :)
The reason is that this kind of pattern has proven to be less reliable
than others, in particular in case of intermediaries that buffer the
response.
Then of course each case is different.
Also, with websocket, the need for these tricks is much less needed.
> The documentation warns us about DOS problems : "If many responses are to be sent (e.g., a chat room),
> then writing one response may block and cause a DOS on the other responses.". If the response.write method
> blocks, then there is also a risk to block a thread if the client is slow and cannot read all the messages
> send as quickly as they are send.
>
> But it seems that Jetty can use async processing of streams provided by NIO. Is it possible to obtain a response
> that uses async writes in order to avoid blocking problems ?
>
> Please, take a little time to answer me and give your opinion.
If you need to solve server-side event broadcasting, then CometD
(http://cometd.org) is a project based on Jetty continuations that
offers just that, with a simpler API and great scalability.
You can look at the documentation here:
http://cometd.org/documentation, the current version is 2.2.0 and soon
2.3.0 will be out.
Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
