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