Pure pub/sub behavior in Reverse Ajax

[chago]

I have an expectation from Reverse AJAX that may not be compatible with DWR's implementation. I was wondering if someone can clear this up, or if I am just seeing an outstanding bug:
http://www.nabble.com/Jetty-and-Reverse-Ajax-Performance-tf3366524.html#a9394546

I am testing the clock example that uses comet to send a ScriptBuffer to a client every second. I am also using Jetty in embedded mode on the server and FF 2.0.0.3 on the client. The call to dwr.engine._poll() is occuring just fine when my page loads. (I am seeing a call to _poll() timeout every 10 successive calls or so, as others have reported.)

My question is whether I should expect regular DWR calls to return their results on the _poll() connection, or do these calls keep their own connection open until the server has satisfied their request?

Thanks,
Jim

[Joe Walker-3]

_poll() does by default keep the connection open (or to be more accurate, it asks the server to keep the connection open).

RC4 (out later on today, I hope) has some fixes for Jetty in embedded mode.

Joe.

On 4/2/07, chago <nabble@...> wrote:

I have an expectation from Reverse AJAX that may not be compatible with DWR's
implementation. I was wondering if someone can clear this up, or if I am
just seeing an outstanding bug:
http://www.nabble.com/Jetty-and-Reverse-Ajax-Performance-tf3366524.html#a9394546

I am testing the clock example that uses comet to send a ScriptBuffer to a
client every second. I am also using Jetty in embedded mode on the server
and FF 2.0.0.3 on the client. The call to dwr.engine._poll() is occuring
just fine when my page loads. (I am seeing a call to _poll() timeout every
10 successive calls or so, as others have reported.)

My question is whether I should expect regular DWR calls to return their
results on the _poll() connection, or do these calls keep their own
connection open until the server has satisfied their request?

Thanks,
Jim
--
View this message in context: http://www.nabble.com/Pure-pub-sub-behavior-in-Reverse-Ajax-tf3506668.html#a9793824
Sent from the DWR - Users mailing list archive at Nabble.com.

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

[chago]

I see that _poll() does keep the connection open, but is there any support to do this?

1. invoke _poll()
2. make a DWR call to a long-running remote method on the server
3. return from the DWR call immediately. No callbacks are invoked. (Server side obviously makes an async call to process the request and the client has to store the callback method until a response is received.)
4. When the response is ready, it is returned via the _poll() connection.
5. The client marries the response to its original callback method and invokes.

I have the above working with ActiveMQ and their AJAX gateway. The problem I am facing is that they only support the transmission of XML data, so I added the DWR conversion classes to their stack and now I can send JSON down to the client. Now I want to add this type of disconnected request-response to their client javascript.

As I'm adding all of this DWR goodness to their stack, I'm realizing it would be nicer if I added a JMS "creator" to DWR. However, there may be some major architectural hurdles if your _poll() routine does not work the way I describe above.

What I like about the pure messaging route is a long-running server side process will block the DWR calls even when I am using Reverse AJAX. Just two of them and my client will freeze (because the _poll() is using one of two connections).

Joe Walker-3 wrote:

_poll() does by default keep the connection open (or to be more accurate, it
asks the server to keep the connection open).

RC4 (out later on today, I hope) has some fixes for Jetty in embedded mode.

Joe.

On 4/2/07, chago <[e-mail]> wrote:
>
>
> I have an expectation from Reverse AJAX that may not be compatible with
> DWR's
> implementation. I was wondering if someone can clear this up, or if I am
> just seeing an outstanding bug:
>
> http://www.nabble.com/Jetty-and-Reverse-Ajax-Performance-tf3366524.html#a9394546
>
> I am testing the clock example that uses comet to send a ScriptBuffer to a
> client every second. I am also using Jetty in embedded mode on the server
> and FF 2.0.0.3 on the client. The call to dwr.engine._poll() is occuring
> just fine when my page loads. (I am seeing a call to _poll() timeout every
> 10 successive calls or so, as others have reported.)
>
> My question is whether I should expect regular DWR calls to return their
> results on the _poll() connection, or do these calls keep their own
> connection open until the server has satisfied their request?
>
> Thanks,
> Jim
> --
> View this message in context:
> http://www.nabble.com/Pure-pub-sub-behavior-in-Reverse-Ajax-tf3506668.html#a9793824
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Joe Walker-3]

JMS is absolutely on the plan.
The idea is to be a JMS provider on the server and an open-ajax hub plug-in on the clients, so you can get a federation of pub/sub providers.
You can make DWR use less connection time by configuring it to polling if you want.

Joe.

On 4/10/07, chago <nabble@...> wrote:

I see that _poll() does keep the connection open, but is there any support to
do this?

1. invoke _poll()
2. make a DWR call to a long-running remote method on the server
3. return from the DWR call immediately. No callbacks are invoked. (Server
side obviously makes an async call to process the request and the client has
to store the callback method until a response is received.)
4. When the response is ready, it is returned via the _poll() connection.
5. The client marries the response to its original callback method and
invokes.

I have the above working with ActiveMQ and their AJAX gateway. The problem I
am facing is that they only support the transmission of XML data, so I added
the DWR conversion classes to their stack and now I can send JSON down to
the client. Now I want to add this type of disconnected request-response to
their client javascript.

As I'm adding all of this DWR goodness to their stack, I'm realizing it
would be nicer if I added a JMS "creator" to DWR. However, there may be some
major architectural hurdles if your _poll() routine does not work the way I
describe above.

What I like about the pure messaging route is a long-running server side
process will block the DWR calls even when I am using Reverse AJAX. Just two
of them and my client will freeze (because the _poll() is using one of two
connections).


Joe Walker-3 wrote:

>
> _poll() does by default keep the connection open (or to be more accurate,
> it
> asks the server to keep the connection open).
>
> RC4 (out later on today, I hope) has some fixes for Jetty in embedded
> mode.
>
> Joe.
>
> On 4/2/07, chago < nabble@...> wrote:
>>
>>
>> I have an expectation from Reverse AJAX that may not be compatible with
>> DWR's
>> implementation. I was wondering if someone can clear this up, or if I am
>> just seeing an outstanding bug:
>>
>> http://www.nabble.com/Jetty-and-Reverse-Ajax-Performance-tf3366524.html#a9394546
>>
>> I am testing the clock example that uses comet to send a ScriptBuffer to
>> a
>> client every second. I am also using Jetty in embedded mode on the server
>> and FF 2.0.0.3 on the client. The call to dwr.engine._poll() is occuring
>> just fine when my page loads. (I am seeing a call to _poll() timeout
>> every
>> 10 successive calls or so, as others have reported.)
>>
>> My question is whether I should expect regular DWR calls to return their
>> results on the _poll() connection, or do these calls keep their own
>> connection open until the server has satisfied their request?
>>
>> Thanks,
>> Jim
>> --
>> View this message in context:
>> http://www.nabble.com/Pure-pub-sub-behavior-in-Reverse-Ajax-tf3506668.html#a9793824
>> Sent from the DWR - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Pure-pub-sub-behavior-in-Reverse-Ajax-tf3506668.html#a9919628
Sent from the DWR - Users mailing list archive at Nabble.com.

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

[chago]

Thanks, that is good to know. I'll take a look at the open-ajax hub and see if I can get Active MQ supplying it with feeds.

Is there a mailing list for the hub? I'm curious to know if it is the hub's responsibility to support the request-response metaphor, or will that still be the responsibility of the client javascript?

-- jim

Joe Walker-3 wrote:

JMS is absolutely on the plan.
The idea is to be a JMS provider on the server and an open-ajax hub plug-in
on the clients, so you can get a federation of pub/sub providers.
You can make DWR use less connection time by configuring it to polling if
you want.

Joe.

[chago]

But there isn't any way to prevent a _poll() and a single long-running DWR request from blocking further requests to the server, correct?

Joe Walker-3 wrote:

You can make DWR use less connection time by configuring it to polling if
you want.

[Joe Walker-3]

If you are using polling instead of comet then DWR does not keep any connections open at all.
In addition DWR does have some mechanics to induce semi-polling behaviour when more than one window is looking at the same server. Although this only works within DWR, not between DWR and ActiveMatrix

Joe.

On 4/10/07, chago <nabble@...> wrote:

But there isn't any way to prevent a _poll() and a single long-running DWR
request from blocking further requests to the server, correct?


Joe Walker-3 wrote:
>
> You can make DWR use less connection time by configuring it to polling if
> you want.
>

[dio]

Is there any update for JMS usage with DWR? Basically my question; is it possible any DWR POJO can pass the caller page/session context to JMS Message Driven Bean by sending a messaeg to JMS queue and MDB can return the result to to caller HTML page when finish processing by using passed by using the sent page util.   Thanks



Thanks, that is good to know. I'll take a look at the open-ajax hub and see if I can get Active MQ supplying it with feeds.

Is there a mailing list for the hub? I'm curious to know if it is the hub's responsibility to support the request-response metaphor, or will that still be the responsibility of the client javascript?

-- jim

Joe Walker-3 wrote:

JMS is absolutely on the plan.
The idea is to be a JMS provider on the server and an open-ajax hub plug-in
on the clients, so you can get a federation of pub/sub providers.
You can make DWR use less connection time by configuring it to polling if
you want.

Joe.

[Lance Semmens-3]

DWR is running in the web-tier whereas MDBs run in the EJB tier. It's probably easiest to have a JMS service running in the web tier using something like Spring JMS instead of using an MDB (http://www-128.ibm.com/developerworks/web/library/wa-spring4/).

Cheers,
Lance.

dio wrote:

Is there any update for JMS usage with DWR? Basically my question; is it
possible any DWR POJO can pass the caller page/session context to JMS
Message Driven Bean by sending a messaeg to JMS queue and MDB can return the
result to to caller HTML page when finish processing by using passed by
using the sent page util.   Thanks



chago wrote:
  

Thanks, that is good to know. I'll take a look at the open-ajax hub and
see if I can get Active MQ supplying it with feeds. 

Is there a mailing list for the hub? I'm curious to know if it is the
hub's responsibility to support the request-response metaphor, or will
that still be the responsibility of the client javascript?

-- jim



Joe Walker-3 wrote:
    

JMS is absolutely on the plan.
The idea is to be a JMS provider on the server and an open-ajax hub
plug-in
on the clients, so you can get a federation of pub/sub providers.
You can make DWR use less connection time by configuring it to polling if
you want.

Joe.


      

[Sanjiv Jivan]

Sounds really cool. Is this planned on being a standalone DWR API or possibly integrated with Tibco's Pagebus?

Thanks,
Sanjiv

On 4/10/07, Joe Walker <joe@...> wrote:

If you are using polling instead of comet then DWR does not keep any connections open at all.
In addition DWR does have some mechanics to induce semi-polling behaviour when more than one window is looking at the same server. Although this only works within DWR, not between DWR and ActiveMatrix

Joe.

On 4/10/07, chago <nabble@...> wrote:

But there isn't any way to prevent a _poll() and a single long-running DWR
request from blocking further requests to the server, correct?


Joe Walker-3 wrote:
>
> You can make DWR use less connection time by configuring it to polling if
> you want.
>

[dio]

This means using MDP (message driven POJOS) rather than MDBs with Spring framework would work.
Has Any one this sort of experience for processing DWR requests on the server via JMS or Quartz job scheduler and returning the results back to the original web page asynchronously?

Can also any one give some feedback about the DWR JMS Support may happen in the future from technological point of view?

Thanks,

-- Deha Peker

Lance Semmens-3 wrote:

DWR is running in the web-tier whereas MDBs run in the EJB tier. It's
probably easiest to have a JMS service running in the web tier using
something like Spring JMS instead of using an MDB
(http://www-128.ibm.com/developerworks/web/library/wa-spring4/).

Cheers,
Lance.

dio wrote:
> Is there any update for JMS usage with DWR? Basically my question; is it
> possible any DWR POJO can pass the caller page/session context to JMS
> Message Driven Bean by sending a messaeg to JMS queue and MDB can return the
> result to to caller HTML page when finish processing by using passed by
> using the sent page util.   Thanks
>
>
>
> chago wrote:
>  
>> Thanks, that is good to know. I'll take a look at the open-ajax hub and
>> see if I can get Active MQ supplying it with feeds.
>>
>> Is there a mailing list for the hub? I'm curious to know if it is the
>> hub's responsibility to support the request-response metaphor, or will
>> that still be the responsibility of the client javascript?
>>
>> -- jim
>>
>>
>>
>> Joe Walker-3 wrote:
>>    
>>> JMS is absolutely on the plan.
>>> The idea is to be a JMS provider on the server and an open-ajax hub
>>> plug-in
>>> on the clients, so you can get a federation of pub/sub providers.
>>> You can make DWR use less connection time by configuring it to polling if
>>> you want.
>>>
>>> Joe.
>>>
>>>
>>>      
>>    
>
>  

[Andreas Wallén]

Well, I'm using DWR in the following scenario:

Using spring, create a bean that's "ServletContextAware". Then you do
something like this in a method:

ServerContext sctx = ServerContextFactory.get(servletContext);
Collection<ScriptSession> scriptSessions =
sctx.getScriptSessionsByPage("some URL");
for (ScriptSession sess : scriptSessions) {
            sess.addScript(etc....);
 }

This bean is injected into a Quartz Job that does background work and
when I choose to, propagates updates to the connected web clients. I
have a number of different quartz jobs runnning updating different web
views. Works great!

Best regards,

Andreas Wallén

On 9/21/07, dio <deha.peker@...> wrote:

>
> This means using MDP (message driven POJOS) rather than MDBs with Spring
> framework would work.
> Has Any one this sort of experience for processing DWR requests on the
> server via JMS or Quartz job scheduler and returning the results back to the
> original web page asynchronously?
>
> Can also any one give some feedback about the DWR JMS Support may happen in
> the future from technological point of view?
>
> Thanks,
>
> -- Deha Peker
>
>
> Lance Semmens-3 wrote:
> >
> > DWR is running in the web-tier whereas MDBs run in the EJB tier. It's
> > probably easiest to have a JMS service running in the web tier using
> > something like Spring JMS instead of using an MDB
> > (http://www-128.ibm.com/developerworks/web/library/wa-spring4/).
> >
> > Cheers,
> > Lance.
> >
> > dio wrote:
> >> Is there any update for JMS usage with DWR? Basically my question; is it
> >> possible any DWR POJO can pass the caller page/session context to JMS
> >> Message Driven Bean by sending a messaeg to JMS queue and MDB can return
> >> the
> >> result to to caller HTML page when finish processing by using passed by
> >> using the sent page util.   Thanks
> >>
> >>
> >>
> >> chago wrote:
> >>
> >>> Thanks, that is good to know. I'll take a look at the open-ajax hub and
> >>> see if I can get Active MQ supplying it with feeds.
> >>>
> >>> Is there a mailing list for the hub? I'm curious to know if it is the
> >>> hub's responsibility to support the request-response metaphor, or will
> >>> that still be the responsibility of the client javascript?
> >>>
> >>> -- jim
> >>>
> >>>
> >>>
> >>> Joe Walker-3 wrote:
> >>>
> >>>> JMS is absolutely on the plan.
> >>>> The idea is to be a JMS provider on the server and an open-ajax hub
> >>>> plug-in
> >>>> on the clients, so you can get a federation of pub/sub providers.
> >>>> You can make DWR use less connection time by configuring it to polling
> >>>> if
> >>>> you want.
> >>>>
> >>>> Joe.
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Pure-pub-sub-behavior-in-Reverse-Ajax-tf3506668.html#a12806843
> Sent from the DWR - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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