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 <[email protected]> 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
