Weblogic / Tomcat Async Servlet support

[Joe Walker-3]

Ken, Randy and anyone else on the developers mailing list,

A number of people have expressed an interest in getting DWR to support
Weblogic async servlets. So I'm hoping to start the ball rolling.

Plan:
- Remove support for Jetty Continuations
- Refactor PollHandler so it can be called from a Weblogic Async Servlet
as well as a standard servlet
- Define an interface which is something close to where we think Servlet
3.0 async servlets are going
- Convert the refactored PollHandler to use this interface and create an
implementation for Jetty and Weblogic

At least 3 people have expressed an interest in working on this. Ken Tam
from BEA, Randy Jones (a Weblogic and DWR user) and a colleague of Ken's
(who's card I missed) at JavaOne.

Am I right in thinking that the best docs on the Weblogic way of doing
things are here:
http://edocs.bea.com/wls/docs91/notes/new.html#1240284

The Developers mailing list (copied) is the best place to discuss this.
Thanks,

Joe.

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

[Joe Walker-3]

Ken Tam wrote:
> My understanding is that Servlet EG discussions thus far have not come
> close to consensus on what the shape of an async API would look like..
> I'd be happy to be wrong :P.
I went to the last EG meeting and my feeling was that Sun already had
something internally that they wanted to propose, but that they were not
ready to publish yet.
>   Greg's servlet coordinator proposal might
> be the closest candidate, but I'm not even sure if that exists in public
> code anywhere (I didn't notice it in jetty last I looked).
>  
 From talking to Greg - I'm fairly sure it's not in Jetty. My original
plan was to convert DWR to Jetty async servlets first, but Greg says
they don't exist.


On a side note, I've opened the dev@... mailing list so
that anyone can post. You can also use Nabble:
http://www.nabble.com/DWR---Dev-f13937.html


Another side note: I'm developing on MacOS. Is there any way to get
Weblogic to run under MacOS, or do I need to keep VMWare or Parallels up
for testing?

Thanks,

Joe.

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

[Randy Jones-2]

Unless Tam or one of the other BEA guys wants to tackle it, I'll start
looking at porting over the Jetty version into the BEA async servlet
version on Friday.

Randy

-----Original Message-----
From: Joe Walker [mailto:joe@...] On Behalf Of Joe Walker
Sent: Wednesday, May 23, 2007 6:50 AM
To: Ken Tam
Cc: Randy Jones; dev@...; Srinagesh Susarla; Prasanth
Pallamreddy
Subject: Re: Weblogic / Tomcat Async Servlet support


Ken Tam wrote:
> My understanding is that Servlet EG discussions thus far have not come
> close to consensus on what the shape of an async API would look like..
> I'd be happy to be wrong :P.
I went to the last EG meeting and my feeling was that Sun already had
something internally that they wanted to propose, but that they were not

ready to publish yet.
>   Greg's servlet coordinator proposal might
> be the closest candidate, but I'm not even sure if that exists in
public
> code anywhere (I didn't notice it in jetty last I looked).
>  
 From talking to Greg - I'm fairly sure it's not in Jetty. My original
plan was to convert DWR to Jetty async servlets first, but Greg says
they don't exist.


On a side note, I've opened the dev@... mailing list so
that anyone can post. You can also use Nabble:
http://www.nabble.com/DWR---Dev-f13937.html


Another side note: I'm developing on MacOS. Is there any way to get
Weblogic to run under MacOS, or do I need to keep VMWare or Parallels up

for testing?

Thanks,

Joe.


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

[Joe Walker-3]

Just looking at some deadlock issues and thinking about how this would work.
The documentation you linked to earlier has gone. Is there a new location?

 From looking through this:
http://edocs.bea.com/wls/docs100/javadocs/index.html

I've got some questions:
- When is it OK to use the output stream? Do I need to wait until I
doResponse() - If so, I'm not impressed because DWR won't be able to
stream data without locking a thread. If not, what's the point in the
method?
- Am I right in thinking that I will need to cache both the servlet and
the RequestResponseKey in order to be able to call notify()?

I've attached my quick sketch of what I think the life-cycle is. Please
could you tell me if my thinking is correct?

Finally is there a way to run Weblogic on a Mac, for that matter is
there a way to download it for XP - all the downloads I can see are for
2000/2003?

Thanks.

Joe.


Ken Tam wrote:

> I've looped in Nagesh and Prash who are also from BEA and interested in
> helping make this happen.
>
> For anyone interested in background on the Weblogic async servlet API,
> the best link is probably:
>
> http://webservice.bea.com:7001/examplesWebApp/docs/core/index.html
>
> (navigate into Weblogic Server Examples / Examples / API / Web
> Application / AbstractAsyncServlet).
>
> My understanding is that Servlet EG discussions thus far have not come
> close to consensus on what the shape of an async API would look like..
> I'd be happy to be wrong :P.  Greg's servlet coordinator proposal might
> be the closest candidate, but I'm not even sure if that exists in public
> code anywhere (I didn't notice it in jetty last I looked).
>
>  
>> -----Original Message-----
>> From: Joe Walker [mailto:joe@...] On Behalf Of Joe Walker
>> Sent: Sunday, May 20, 2007 5:24 AM
>> To: Ken Tam; randy_jones@...; dev@...
>> Subject: Weblogic / Tomcat Async Servlet support
>>
>>
>> Ken, Randy and anyone else on the developers mailing list,
>>
>> A number of people have expressed an interest in getting DWR
>> to support
>> Weblogic async servlets. So I'm hoping to start the ball rolling.
>>
>> Plan:
>> - Remove support for Jetty Continuations
>> - Refactor PollHandler so it can be called from a Weblogic
>> Async Servlet
>> as well as a standard servlet
>> - Define an interface which is something close to where we
>> think Servlet
>> 3.0 async servlets are going
>> - Convert the refactored PollHandler to use this interface
>> and create an
>> implementation for Jetty and Weblogic
>>
>> At least 3 people have expressed an interest in working on
>> this. Ken Tam
>> from BEA, Randy Jones (a Weblogic and DWR user) and a
>> colleague of Ken's
>> (who's card I missed) at JavaOne.
>>
>> Am I right in thinking that the best docs on the Weblogic way
>> of doing
>> things are here:
>> http://edocs.bea.com/wls/docs91/notes/new.html#1240284
>>
>> The Developers mailing list (copied) is the best place to
>> discuss this.
>> Thanks,
>>
>> Joe.
>>
>>
>>    

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

[Srinagesh Susarla]

Hi Joe,

Response inline ...

You've got the picture right, except that
Servlet.doTimeout(RequestResponseKey) is called when a notify(..) is not
called within the specified timeout period.

> I've got some questions:
> - When is it OK to use the output stream? Do I need to wait until I
> doResponse() - If so, I'm not impressed because DWR won't be
> able to stream data without locking a thread. If not, what's
> the point in the method?

Are you trying to sending multiple responses or just one response? The
API was written such that when an interesting event happens some code
would call Servlet.notify(key..) which inturn would call doResponse(..)
which is reponsible for writing the response.  
Can you explain your usecase a little more.


> - Am I right in thinking that I will need to cache both the
> servlet and the RequestResponseKey in order to be able to
> call notify()?
>

Caching just the RequestResponseKey would suffice, since notify(..) is a
static method


> I've attached my quick sketch of what I think the life-cycle
> is. Please could you tell me if my thinking is correct?
>
> Finally is there a way to run Weblogic on a Mac, for that
> matter is there a way to download it for XP - all the
> downloads I can see are for 2000/2003?
>

The 2000/2003 version should work on XP.

Unfortunately I havent tried this myself but you could try using the AIX
installer (which is a generic install) on OSX. Here's a link with some
user comments on this topic.

http://forums.bea.com/bea/message.jspa?messageID=600040809&tstart=0


Thanks,
-- Nagesh
 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

[Ken Tam-3]

> You've got the picture right, except that
> Servlet.doTimeout(RequestResponseKey) is called when a notify(..) is not
> called within the specified timeout period.
>
> > I've got some questions:
> > - When is it OK to use the output stream? Do I need to wait until I
> > doResponse() - If so, I'm not impressed because DWR won't be
> > able to stream data without locking a thread. If not, what's
> > the point in the method?
>
> Are you trying to sending multiple responses or just one response? The
> API was written such that when an interesting event happens some code
> would call Servlet.notify(key..) which inturn would call doResponse(..)
> which is reponsible for writing the response.
> Can you explain your usecase a little more.

Based on the description @
http://getahead.org/dwr/reverse-ajax/configuration, I'm guessing that
DWR's default "Full Streaming Mode" is using HTTP streaming by writing
to the same response multiple times over an extended period (and
freeing up the thread between writes).  If that's the case, I see a
few options:

1) We've had talks about modifying the AbstractAsyncServlet API to
support the multiple  so that doResponse() returns a bool w/ similar
semantics to the return value for doRequest() -- ie, returning true
would imply the request gets re-suspended, and notify() could be
called on it again.

2) Since #1 would require changes to the WLS API, it isn't a solution
today -- I think we are limited to using the "Early Closing Mode".
Not completely optimal since we are issuing more requests, but it'll
still be noticeably more efficient than without the async servlet
since we won't be holding the thread while waiting.

Joe, am I on the right track here?

> > Finally is there a way to run Weblogic on a Mac, for that
> > matter is there a way to download it for XP - all the
> > downloads I can see are for 2000/2003?
> >
>
> The 2000/2003 version should work on XP.
>
> Unfortunately I havent tried this myself but you could try using the AIX
> installer (which is a generic install) on OSX. Here's a link with some
> user comments on this topic.
>
> http://forums.bea.com/bea/message.jspa?messageID=600040809&tstart=0

Here's another link with info on doing this:

http://blog.refactor.se/2007/04/02/weblogic-10-on-os-x/

cheers,
k

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

[Joe Walker-3]

On 6/21/07, Ken Tam <kentaminator@...> wrote:

Based on the description @
http://getahead.org/dwr/reverse-ajax/configuration, I'm guessing that
DWR's default "Full Streaming Mode" is using HTTP streaming by writing
to the same response multiple times over an extended period (and
freeing up the thread between writes).  If that's the case, I see a
few options:

1) We've had talks about modifying the AbstractAsyncServlet API to
support the multiple  so that doResponse() returns a bool w/ similar
semantics to the return value for doRequest() -- ie, returning true
would imply the request gets re-suspended, and notify() could be
called on it again.

Is there anything wrong with allowing calls to RequestResponseKey.getResponse.getWriter.write at any time?

2) Since #1 would require changes to the WLS API, it isn't a solution
today -- I think we are limited to using the "Early Closing Mode".
Not completely optimal since we are issuing more requests, but it'll
still be noticeably more efficient than without the async servlet
since we won't be holding the thread while waiting.

Joe, am I on the right track here?

Yes.
I've just made some significant changes to the guts of PollHandler to make it easier to understand, and to allow weblogic integration.

The logic is now like this:

PollHandler does the following (copied/simplified from another thread):

• Parse the request, check for errors etc
• 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 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.

What we will need to do to support WL is to create a special Conduit that stores the data rather than passing it on. We'll also need to do something nasty to get the clear-up action called at the right time. I think we'll also need to ensure that the OutputAlarm is configured. We'll probably also need a custom ServerLoadMonitor, and I'm hoping that WL can do some real value add here.

> http://forums.bea.com/bea/message.jspa?messageID=600040809&tstart=0

Here's another link with info on doing this:

http://blog.refactor.se/2007/04/02/weblogic-10-on-os-x/

Thanks.
As far as I'm concerned I've done the clean-up that I wanted to do to make async servlets in general easier to support, so I will be concentrating on other 2.1 features for a while. If no-one else works on this - I'll probably tackle it in the 2.2 timeframe, but if someone else is willing to work on it, I'm happy to help.

Joe.

[Randy Jones-2]

Joe,

 

I know I keep saying that I'm goign to work on this and I'm really willing to help, but I keep getting slammed at work. Its one of those deals where I keep telling myself it will be better next week...it never is. My wife is out of town so I might be able to get the latest from cvs and start looking at this over the next few nights.

 

Randy

---

From: joseph.walker@... on behalf of Joe Walker
Sent: Sun 6/24/2007 5:40 AM
To: dev@...; kentaminator@...
Subject: Re: [dwr-dev] RE: Weblogic / Tomcat Async Servlet support

On 6/21/07, Ken Tam <kentaminator@...> wrote:

Based on the description @
http://getahead.org/dwr/reverse-ajax/configuration, I'm guessing that
DWR's default "Full Streaming Mode" is using HTTP streaming by writing
to the same response multiple times over an extended period (and
freeing up the thread between writes).  If that's the case, I see a
few options:

1) We've had talks about modifying the AbstractAsyncServlet API to
support the multiple  so that doResponse() returns a bool w/ similar
semantics to the return value for doRequest() -- ie, returning true
would imply the request gets re-suspended, and notify() could be
called on it again.

Is there anything wrong with allowing calls to RequestResponseKey.getResponse.getWriter.write at any time?

2) Since #1 would require changes to the WLS API, it isn't a solution
today -- I think we are limited to using the "Early Closing Mode".
Not completely optimal since we are issuing more requests, but it'll
still be noticeably more efficient than without the async servlet
since we won't be holding the thread while waiting.

Joe, am I on the right track here?

Yes.
I've just made some significant changes to the guts of PollHandler to make it easier to understand, and to allow weblogic integration.

The logic is now like this:

PollHandler does the following (copied/simplified from another thread):

• Parse the request, check for errors etc
• 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 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.

What we will need to do to support WL is to create a special Conduit that stores the data rather than passing it on. We'll also need to do something nasty to get the clear-up action called at the right time. I think we'll also need to ensure that the OutputAlarm is configured. We'll probably also need a custom ServerLoadMonitor, and I'm hoping that WL can do some real value add here.

> http://forums.bea.com/bea/message.jspa?messageID=600040809&tstart=0

Here's another link with info on doing this:

http://blog.refactor.se/2007/04/02/weblogic-10-on-os-x/

Thanks.
As far as I'm concerned I've done the clean-up that I wanted to do to make async servlets in general easier to support, so I will be concentrating on other 2.1 features for a while. If no-one else works on this - I'll probably tackle it in the 2.2 timeframe, but if someone else is willing to work on it, I'm happy to help.

Joe.

[Joe Walker-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

So the steps are:

1. Take the logic in DwrServlet and put it into a WL AsyncServlet, and effectively get the sync code to be fired off asyncronously. It should be possible to simply get DWR working as is with a new servlet. All the writing would be done in doResponse().

2. Create a fake response object that stores responses so you can write in doRequest() and the flush properly when doResponse() is called.

3. Create a WeblogicSleeper that wakes up by calling doResponse()

4. I think we will need a custom WeblogicServerLoadMonitor that says no-streaming.

Ken/etc - what does Weblogic know about how loaded it is? In writing a server load monitor which can ask clients to poll less often can we tell how near we are to Weblogic running out of servlets, or nearing a high-tide mark in the hits it's sustaining?

Joe.

On 6/26/07, Randy Jones <randy_jones@...> wrote:

Joe,

 

I know I keep saying that I'm goign to work on this and I'm really willing to help, but I keep getting slammed at work. Its one of those deals where I keep telling myself it will be better next week...it never is. My wife is out of town so I might be able to get the latest from cvs and start looking at this over the next few nights.

 

Randy

---

From: joseph.walker@... on behalf of Joe Walker
Sent: Sun 6/24/2007 5:40 AM
To: dev@...; kentaminator@...
Subject: Re: [dwr-dev] RE: Weblogic / Tomcat Async Servlet support

On 6/21/07, Ken Tam <kentaminator@...> wrote:

Based on the description @
http://getahead.org/dwr/reverse-ajax/configuration, I'm guessing that
DWR's default "Full Streaming Mode" is using HTTP streaming by writing
to the same response multiple times over an extended period (and
freeing up the thread between writes).  If that's the case, I see a
few options:

1) We've had talks about modifying the AbstractAsyncServlet API to
support the multiple  so that doResponse() returns a bool w/ similar
semantics to the return value for doRequest() -- ie, returning true
would imply the request gets re-suspended, and notify() could be
called on it again.

Is there anything wrong with allowing calls to RequestResponseKey.getResponse.getWriter.write at any time?

2) Since #1 would require changes to the WLS API, it isn't a solution
today -- I think we are limited to using the "Early Closing Mode".
Not completely optimal since we are issuing more requests, but it'll
still be noticeably more efficient than without the async servlet
since we won't be holding the thread while waiting.

Joe, am I on the right track here?

Yes.
I've just made some significant changes to the guts of PollHandler to make it easier to understand, and to allow weblogic integration.

The logic is now like this:

PollHandler does the following (copied/simplified from another thread):

• Parse the request, check for errors etc
• 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 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.

What we will need to do to support WL is to create a special Conduit that stores the data rather than passing it on. We'll also need to do something nasty to get the clear-up action called at the right time. I think we'll also need to ensure that the OutputAlarm is configured. We'll probably also need a custom ServerLoadMonitor, and I'm hoping that WL can do some real value add here.

> http://forums.bea.com/bea/message.jspa?messageID=600040809&tstart=0

Here's another link with info on doing this:

http://blog.refactor.se/2007/04/02/weblogic-10-on-os-x/

Thanks.
As far as I'm concerned I've done the clean-up that I wanted to do to make async servlets in general easier to support, so I will be concentrating on other 2.1 features for a while. If no-one else works on this - I'll probably tackle it in the 2.2 timeframe, but if someone else is willing to work on it, I'm happy to help.

Joe.