Re: DWR + Bayeux

[Joe Walker-3]

Copied to the dwr-dev mailing list in case anyone there is interested.

Not looked at this in depth yet.
Let me explain my current thinking:

PollHandler does the following:

• (Jetty hack - come to this later)
• Parse the request, check for errors etc
• Check for 2 requests from the same browser, kick the other guy out
• Create a conduit to allow things to write to the browser, register with ScriptSession
• Create a Sleeper. A Sleeper is a way to go to sleep and wake up again. Currently there is a JettyContinuationSleeper and a ThreadWaitSleeper. We'll probably add a AsyncServletSleeper
• Create some Alarms. We need a TimedAlarm to wake the sleeper after X seconds, a ShutdownAlarm so the Server can gracefully shutdown and if the browser can't do streaming we also need an OutputAlarm. The OutputAlarm knows about the Script session so it can detect output happening.
• All of these Alarms need to know about the Sleeper so they can wake it up.
• We then create a 'clear-up' action (a Runnable) that cancels the Alarms that have not gone off and tells the browser to come back at a later date. This action is not executed yet.
• The we tell the Sleeper to go to sleep and to execute the clear-up action when it awakes.
• For the AsyncServletSleeper and ThreadWaitSleeper it's easy to work out when to run the clear-up action. For the JettyContinuationSleeper we have a hack (see the top of the list) that runs the clear-up action when the Continuation re-starts.

I feel *much* happier with this than the old system. Simply organizing it like this has made me understand several bugs that I didn't know existed, and I have some hope that it will fix the nasty race conditions that people are reporting on 2.0.2

Assuming that you can't spot a flaw in the plan, I'll finish it off and incorporate your changes for Bayeux.

Joe.


Greg Wilkins wrote:

Joe,

just as I got it working... I see that you had done a bit of work on it!

But very similar approach - so that's good.

Anyway, this is still a bit of a hack, but I think it is a good start.

The only change I needed to core DWR was for the PlainCallMarshaller to
expose a marshallInbound(Batch) method.

I changed the approach to configuration a bit.  Instead of the BayeuxClient
creating it's own configuration, the listener listens for the containers
attribute of the normal DwrServlet and injects the required objects into
the BayeuxClient.

I've upgraded everything to jetty-6.1.4 classes, which includes the
latest "standard" dojox.cometd API, so there is no mortbay code linked
to (but there is a class in the web.xml).  It needs the dojo.js (0.9
patched with cometd baked in) that is in the tarred example.

I copied the simpletext example into a bayeux example (and it is the
only one I have tested with).

Attached is a patch, plus the files themselves and the dwr-bayeux.js
file, plus the web/bayeux example tarred up.

Oh and there are a few debug printlns left in at the moment.

If you can validate the approach, I'll look at reverse ajax
next

cheers and we'll talk tomorrow.







  

[Greg Wilkins]

Joe,

well other than calling the retry state handling a "Jetty hack" :-),
this looks OK.

BUT!

I would advocate that rather than (re)implement your poll stuff
in a one size fits all approach that will work with waiting, continuations
or the various breeds of async servlet out there....(don't forget
glassfish and grizzly) it is the intent of Bayeux to free you from that drudgery.

If you instead coded to the dojox.cometd API, then you could simply
configure in web.xml a cometd servlet for jetty, tomcat, bea or grizzly
and you would get your comet push optmized for each server without
any one size fits all clutter.

Now I am not advocating ripping out your current comet push mechanism
(at least not yet), but I am suggesting that perhaps you don't spend
a lot of time refactoring for lots of different approaches.

I know Bayeux is young and the dojo impl is a little fat.... but
it is improving and hopefully there will soon be alternate client
side impls.

So if your current push mechanism is not totally bug ridden, I would
suggest that perhaps looking at bayeux a little closer before refactoring.

For normal Ajax, I think you will see that the patch I sent is very
minimal integration and only needs one small change to core classes before
it can be added as an optional extra.  I have not looked at the reverse
stuff yet, but I think some sort of permanent condiut that routes
through to the bayeux API should do it.

The down side of this is approach, is that for scalable push you
will need to depend on another servlet and a client side library.

But the upside, would be that you could trim your current polling
back to just a waiting implementation that gives you dependency free
portability

cheers












Joe Walker wrote:

>
> Copied to the dwr-dev mailing list in case anyone there is interested.
>
> Not looked at this in depth yet.
> Let me explain my current thinking:
>
> PollHandler does the following:
>
>     * (Jetty hack - come to this later)
>     * Parse the request, check for errors etc
>     * Check for 2 requests from the same browser, kick the other guy out
>     * Create a conduit to allow things to write to the browser, register
>       with ScriptSession
>     * Create a Sleeper. A Sleeper is a way to go to sleep and wake up
>       again. Currently there is a JettyContinuationSleeper and a
>       ThreadWaitSleeper. We'll probably add a AsyncServletSleeper
>     * Create some Alarms. We need a TimedAlarm to wake the sleeper after
>       X seconds, a ShutdownAlarm so the Server can gracefully shutdown
>       and if the browser can't do streaming we also need an OutputAlarm.
>       The OutputAlarm knows about the Script session so it can detect
>       output happening.
>     * All of these Alarms need to know about the Sleeper so they can
>       wake it up.
>     * We then create a 'clear-up' action (a Runnable) that cancels the
>       Alarms that have not gone off and tells the browser to come back
>       at a later date. This action is not executed yet.
>     * The we tell the Sleeper to go to sleep and to execute the clear-up
>       action when it awakes.
>     * For the AsyncServletSleeper and ThreadWaitSleeper it's easy to
>       work out when to run the clear-up action. For the
>       JettyContinuationSleeper we have a hack (see the top of the list)
>       that runs the clear-up action when the Continuation re-starts.
>
> I feel *much* happier with this than the old system. Simply organizing
> it like this has made me understand several bugs that I didn't know
> existed, and I have some hope that it will fix the nasty race conditions
> that people are reporting on 2.0.2
>
> Assuming that you can't spot a flaw in the plan, I'll finish it off and
> incorporate your changes for Bayeux.
>
> Joe.
>
>
> Greg Wilkins wrote:
>> Joe,
>>
>> just as I got it working... I see that you had done a bit of work on it!
>>
>> But very similar approach - so that's good.
>>
>> Anyway, this is still a bit of a hack, but I think it is a good start.
>>
>> The only change I needed to core DWR was for the PlainCallMarshaller to
>> expose a marshallInbound(Batch) method.
>>
>> I changed the approach to configuration a bit.  Instead of the BayeuxClient
>> creating it's own configuration, the listener listens for the containers
>> attribute of the normal DwrServlet and injects the required objects into
>> the BayeuxClient.
>>
>> I've upgraded everything to jetty-6.1.4 classes, which includes the
>> latest "standard" dojox.cometd API, so there is no mortbay code linked
>> to (but there is a class in the web.xml).  It needs the dojo.js (0.9
>> patched with cometd baked in) that is in the tarred example.
>>
>> I copied the simpletext example into a bayeux example (and it is the
>> only one I have tested with).
>>
>> Attached is a patch, plus the files themselves and the dwr-bayeux.js
>> file, plus the web/bayeux example tarred up.
>>
>> Oh and there are a few debug printlns left in at the moment.
>>
>> If you can validate the approach, I'll look at reverse ajax
>> next
>>
>> cheers and we'll talk tomorrow.
>>
>>
>>
>>
>>
>>
>>
>>  
>

--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Wilkins]

Joe Walker wrote:
>
> Just integrating this - presumably dwr-bayeux needs to be served by DWR?

Well it depends on how close an integration that you want at this point.

The cost is small, a small js file and a listener class (bat that depends on
dojox.cometd interfaces that are not yet individually bundled).

> I'm thinking it's going to be good if DWR detects that it's in bayeux
> mode and automatically gives you dwr-bayeux along with engine.js?

It would great if it could be done purely additive.  ie zero changes
to core dwr that know about bayeux.

The problem is that the listener can't serve the js itself.  So perhaps
this is a DwrBayeuxFilter instead of a listener.  This can be configured
in front of the standard DWR servlet and intercept engine.js requests and
server back the modified engine.js file (which is the standard engine.js
plus the bayeux bits).

This would mean that rather than:

 0) install dwr
 1) install bayeux
 2) configure bayeux-dwr listener
 3) configure dwr for bayeux

it would simple be

 0) install dwr
 1) install bayeux
 2) configure bayeux-dwr filter


if you like this approach, I'll refactor the patch.

I will also refactor the bayeux project to produce a dojox.cometd jar
with just the interfaces in it.

cheers

> Joe.
>
>
> Greg Wilkins wrote:
>> Joe,
>>
>> just as I got it working... I see that you had done a bit of work on it!
>>
>> But very similar approach - so that's good.
>>
>> Anyway, this is still a bit of a hack, but I think it is a good start.
>>
>> The only change I needed to core DWR was for the PlainCallMarshaller to
>> expose a marshallInbound(Batch) method.
>>
>> I changed the approach to configuration a bit.  Instead of the
>> BayeuxClient
>> creating it's own configuration, the listener listens for the containers
>> attribute of the normal DwrServlet and injects the required objects into
>> the BayeuxClient.
>>
>> I've upgraded everything to jetty-6.1.4 classes, which includes the
>> latest "standard" dojox.cometd API, so there is no mortbay code linked
>> to (but there is a class in the web.xml).  It needs the dojo.js (0.9
>> patched with cometd baked in) that is in the tarred example.
>>
>> I copied the simpletext example into a bayeux example (and it is the
>> only one I have tested with).
>>
>> Attached is a patch, plus the files themselves and the dwr-bayeux.js
>> file, plus the web/bayeux example tarred up.
>>
>> Oh and there are a few debug printlns left in at the moment.
>>
>> If you can validate the approach, I'll look at reverse ajax
>> next
>>
>> cheers and we'll talk tomorrow.
>>
>>
>>
>>
>>
>>
>>
>>  
>

--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Wilkins]

Joe Walker wrote:
> >
> > Just integrating this - presumably dwr-bayeux needs to be served by DWR?
> > I'm thinking it's going to be good if DWR detects that it's in bayeux
> > mode and automatically gives you dwr-bayeux along with engine.js?

Joe,

you have added cometd 6.1.4 jar, but not removed the 6.1.3 one from cvs.


Also, as I have been getting some email bounces.... here is my earlier
response again... just in case.

Joe Walker wrote:
> >
> > Just integrating this - presumably dwr-bayeux needs to be served by DWR?

Well it depends on how close an integration that you want at this point.

The cost is small, a small js file and a listener class (bat that depends on
dojox.cometd interfaces that are not yet individually bundled).

> > I'm thinking it's going to be good if DWR detects that it's in bayeux
> > mode and automatically gives you dwr-bayeux along with engine.js?

It would great if it could be done purely additive.  ie zero changes
to core dwr that know about bayeux.

The problem is that the listener can't serve the js itself.  So perhaps
this is a DwrBayeuxFilter instead of a listener.  This can be configured
in front of the standard DWR servlet and intercept engine.js requests and
server back the modified engine.js file (which is the standard engine.js
plus the bayeux bits).

This would mean that rather than:

 0) install dwr
 1) install bayeux
 2) configure bayeux-dwr listener
 3) configure dwr for bayeux

it would simple be

 0) install dwr
 1) install bayeux
 2) configure bayeux-dwr filter


if you like this approach, I'll refactor the patch.

I will also refactor the bayeux project to produce a dojox.cometd jar
with just the interfaces in it.

cheers









--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Walker-3]

On 6/26/07, Greg Wilkins <gregw@...> wrote:

Joe Walker wrote:
> >
> > Just integrating this - presumably dwr-bayeux needs to be served by DWR?
> > I'm thinking it's going to be good if DWR detects that it's in bayeux
> > mode and automatically gives you dwr-bayeux along with engine.js?

Joe,

you have added cometd 6.1.4 jar, but not removed the 6.1.3 one from cvs.

Yes - thanks.
Will check in soon.

Also, as I have been getting some email bounces.... here is my earlier
response again... just in case.

Joe Walker wrote:
> >
> > Just integrating this - presumably dwr-bayeux needs to be served by DWR?

Well it depends on how close an integration that you want at this point.

The cost is small, a small js file and a listener class (bat that depends on
dojox.cometd interfaces that are not yet individually bundled).

> > I'm thinking it's going to be good if DWR detects that it's in bayeux
> > mode and automatically gives you dwr-bayeux along with engine.js?

It would great if it could be done purely additive.  ie zero changes
to core dwr that know about bayeux.

The problem is that the listener can't serve the js itself.  So perhaps
this is a DwrBayeuxFilter instead of a listener.  This can be configured
in front of the standard DWR servlet and intercept engine.js requests and
server back the modified engine.js file (which is the standard engine.js
plus the bayeux bits).

This would mean that rather than:

0) install dwr
1) install bayeux
2) configure bayeux-dwr listener
3) configure dwr for bayeux

it would simple be

0) install dwr
1) install bayeux
2) configure bayeux-dwr filter


if you like this approach, I'll refactor the patch.

Makes total sense to me

Joe.

[Greg Wilkins]

Joe Walker wrote:
>
>
> On 6/26/07, *Greg Wilkins* <gregw@...
> <mailto:gregw@...>> wrote:

>     It would great if it could be done purely additive.  ie zero changes
>     to core dwr that know about bayeux.

> Makes total sense to me

Attached is a tar of the changes to make this a filter.
It now uses the dwr FileHandler to dynamically put the context
path into the dwrbayeux.js script.

I'll now look at making reverse ajax work (which is the whole point).

cheers


--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Walker-3]

Did the attachment fall off in the mail, or something else ...
Joe.

On 6/27/07, Greg Wilkins <gregw@...> wrote:

Joe Walker wrote:
>
>
> On 6/26/07, *Greg Wilkins* < gregw@...
> <mailto:gregw@...>> wrote:

>     It would great if it could be done purely additive.  ie zero changes
>     to core dwr that know about bayeux.

> Makes total sense to me

Attached is a tar of the changes to make this a filter.
It now uses the dwr FileHandler to dynamically put the context
path into the dwrbayeux.js script.

I'll now look at making reverse ajax work (which is the whole point).

cheers


--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Wilkins]

Joe Walker wrote:
>
> Did the attachment fall off in the mail, or something else ...
> Joe.


DOH!!!!


--
Greg Wilkins<gregw@...>                       US:  [phone]
http://www.webtide.com           UK: [phone] AU: [phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...