Re: FW: [pushlet] Digest Number 246
"Asynch Messaging" <[email protected]> Wed, 24 Sep 2003 22:59:38 -0700
| Newsgroups | gmane.comp.web.mod-pubsub.devel |
|---|---|
| Message-ID | <[email protected]> |
I think that mod-pubsub might be too easy. No joy without banging away on the keyboard all day. ----- Original Message ----- From: "Adam Rifkin" <[email protected]> To: <[email protected]> Sent: Wednesday, September 24, 2003 10:19 PM Subject: [Mod-pubsub-developer] FW: [pushlet] Digest Number 246 Not much here, I just note that the pushlets mailing list is still getting oodles of traffic. :) Adam -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wed 9/24/2003 7:57 PM To: [email protected] Subject: [pushlet] Digest Number 246 To Post a message, send it to: [email protected] To Unsubscribe, send a blank message to: [email protected] ------------------------------------------------------------------------ There are 5 messages in this issue. Topics in this digest: 1. Disconnection not always detected From: "bluebird__99" <[email protected]> 2. Newbie Questions From: "glenn_barnard" <[email protected]> 3. Newbie Questions From: "glenn_barnard" <[email protected]> 4. Re: Disconnection not always detected From: Just van den Broecke <[email protected]> 5. has anyone tried this? From: "tadchristiansen" <[email protected]> ________________________________________________________________________ ________________________________________________________________________ Message: 1 Date: Wed, 24 Sep 2003 12:57:19 -0000 From: "bluebird__99" <[email protected]> Subject: Disconnection not always detected Hi, I am using the same technique as pushlets do in my program. In by far the most cases it works just fine, however, in some cases writing to a disconnected browser does not seem to throw an IOException, and the push remains open and writing. This only really showed up when testing in a commercial environment. As you can imagine, as time goes by, this adds up to lots of open connections staying open, slowing everything down to a crawl. I am wondering if anyone here has encountered this issue and if so, if the cause has been found. Could it be that if people have a firewall that also blocks IMCP packages, that this also blocks error handshaking to the pushing servlet? ________________________________________________________________________ ________________________________________________________________________ Message: 2 Date: Wed, 24 Sep 2003 13:31:23 -0000 From: "glenn_barnard" <[email protected]> Subject: Newbie Questions I've been trying Pushlets for 2 weeks now and have several questions. First a comment related to blocking on the HttpUrlConnection.getInputStream(), I found that when the first response was pushed, the client returned from this statement. I tried commenting out other setHeading() calls, and sending data seemed to be the only common denominator. And now, here are my questions. 1. Is it possible to let the doGet() return after it starts a thread to push events (e.g., put call to processEvents() in a thread started in PushletSubscriber.init())? My testing indicates NO because when the thread tries to push(), it complains the output stream has been closed. Disabling the call setHeader("Connection", "close") is needed for Keep Alive, but doesn't have the affect I desire. 2. Is it possible to use the HTTP connection as a two way communication? I want my client to send status events and request content in addition to receiving content. Can do on another Servlet, but wanted it all in one for simplicity. Thanks for your advice on these questions. ________________________________________________________________________ ________________________________________________________________________ Message: 3 Date: Wed, 24 Sep 2003 13:31:45 -0000 From: "glenn_barnard" <[email protected]> Subject: Newbie Questions I've been trying Pushlets for 2 weeks now and have several questions. First a comment related to blocking on the HttpUrlConnection.getInputStream(), I found that when the first response was pushed, the client returned from this statement. I tried commenting out other setHeading() calls, and sending data seemed to be the only common denominator. And now, here are my questions. 1. Is it possible to let the doGet() return after it starts a thread to push events (e.g., put call to processEvents() in a thread started in PushletSubscriber.init())? My testing indicates NO because when the thread tries to push(), it complains the output stream has been closed. Disabling the call setHeader("Connection", "close") is needed for Keep Alive, but doesn't have the affect I desire. 2. Is it possible to use the HTTP connection as a two way communication? I want my client to send status events and request content in addition to receiving content. Can do on another Servlet, but wanted it all in one for simplicity. Thanks for your advice on these questions. ________________________________________________________________________ ________________________________________________________________________ Message: 4 Date: Wed, 24 Sep 2003 17:11:15 +0200 From: Just van den Broecke <[email protected]> Subject: Re: Disconnection not always detected This issue may occur if you are using JSPs to push (they may eat the IOException). I have not found this issue on my server at www.pushlets.com which sometimes runs for months in a row. ICMP packets are not involved in HTTP communication. What I do have seen in other projects is related to the workings of TCP (which carries HTTP). A TCP connection that is never explicitly closed (e.g. when the client crashes) may remain open for several days (e.g. a telnet/ssh session that is never used). TCP has no end-to-end "ping"-type for signalling that both ends are connected. This is the reason that many distributed technologies like CORBA, DCOM and RMI use a ping-pong/keep-alive protocol underneath to regularly check for lost clients (DCOM even was renown for eating memory because of alloced space). If this is really an issue occurring within the Pushlet framework I may be adding a client-originated acknowledgement. There are also other reasons (see mailing list archive) for doing in order to make the pushlet protocol more robust. Just bluebird__99 wrote: > Hi, > > I am using the same technique as pushlets do in my program. In by far > the most cases it works just fine, however, in some cases writing to a > disconnected browser does not seem to throw an IOException, and the > push remains open and writing. This only really showed up when testing > in a commercial environment. As you can imagine, as time goes by, this > adds up to lots of open connections staying open, slowing everything > down to a crawl. > > I am wondering if anyone here has encountered this issue and if so, if > the cause has been found. Could it be that if people have a firewall > that also blocks IMCP packages, that this also blocks error > handshaking to the pushing servlet? > > > > To Post a message, send it to: [email protected] > To Unsubscribe, send a blank message to: [email protected] > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > -- --Just Just van den Broecke [email protected] Just Objects B.V. tel. +31 65 4268627 The Netherlands http://www.justobjects.nl ________________________________________________________________________ ________________________________________________________________________ Message: 5 Date: Wed, 24 Sep 2003 21:44:44 -0000 From: "tadchristiansen" <[email protected]> Subject: has anyone tried this? Has anyone tried to push information to specific clients (browsers). For example, what if I only wanted to refresh browsers with certain session id's? ________________________________________________________________________ ________________________________________________________________________ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mod-pubsub-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mod-pubsub-developer ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf