Re: [Resin-interest] Fwd: ajax push app - comet/gwt/continuations

2008-05-18 Thread Emil Ong
On Sat, May 17, 2008 at 12:33:08PM -0700, jdk head wrote:
 Hi y'all,
 
 For an ajax push app...
 
 Has anyone had any luck with:
 A) integrating resin's comet support with GWT's server side - extends
 com.google.gwt.user.server.rpc.RemoteServiceServlet ?
 
   • given they both seem to be servlet wrappers, any way can they play nice
 together?

Hi,

I've taken a look at this, but I think the work to do it would be pretty
involved from the GWT side.  Also, you probably wouldn't use the
RemoteServiceServlet on the server side.  In the case of Comet, you
either need to send a message to the client or invoke a procedure on the
client.  Thus what I'd like to see in GWT is the creation of a proxy
for an interface that's implemented on the client.  This whole problem
is much better addressed by HMTP: 

http://www.caucho.com/resin/doc/hmtp.xtp

But I digress... :-) The real underlying problem is that GWT has it's
own RPC format for its RemoteServiceServlet and it needs to be reversed
to send requests to the client and return responses from it.  I think
there's a real opportunity for GWT to create a generic way to handle
this that would work with any Comet/server-push implementation.

 B) resin / continuations?
 C) resin comet / continuations?

I'm not sure why you would want to use continuations with Resin,
given its server-push architecture.  Continuations have nothing
to do with Comet per se, they are just Tomcat's implementation,
except that what Tomcat calls continuations are not.  Java doesn't
support continuations and Tomcat's attempt at them is closer to
SIMD programming than continuations.  SIMD is hard to get right
as a user.  I used to work on MPI, so I know how much difficultly
users have with the concept.

 Maybe comet would be all that's needed.  My main concern is trying to not chew
 up all the threads.

Yup.  Resin's server-push does this just fine.

 Also, any advice on the best way to configure resin to handle a lot of 
 sleeping
 concurrent requests?  Seemingly continuations might help out with the threads
 part, but what about the tcp connections?  Best handled with mod_caucho or
 resin direct?

Check out the latest snapshot.  It's got improvements for timeouts with
server-push and HMTP.  If you can avoid Apache, do it.  Apache support
is only for people who have existing installations with plugins not
available in Resin.  Using Resin's web server is much better integrated
than Apache with Resin.

Best,
Emil



Emil Ong
Chief Evangelist
Caucho Technology, Inc.
Tel. (858) 456-0300
mailto:[EMAIL PROTECTED]
http://blog.caucho.com/

Caucho: Reliable Open Source
-- Resin: application server
-- Quercus: PHP in Java
-- Hessian Web Services


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] Fwd: ajax push app - comet/gwt/continuations

2008-05-18 Thread jdk head
Thanks, Emil, for the quick response

When resin's comet suspends the thread, does it not count against the
thread-max setting?  If not, that's great.

We're pretty deeply committed to GWT right now - lots of implementation
already, so I need to figure out a good way to get GWT to work with resin
comet.  I can think of two possibilities to try:

1) make inital calls to GWT's RemoteServiceServlet, and pass its
getThreadLocalRequest() and getThreadLocalResponse() into the comet servlet
service() and resume().  Then hope the suspension and everything still works
ok

2) make initial calls to a resin comet servlet, then dig into the GWT source
and figure out what classes are doing the serialization of the RPC objects.
Have the comet servlet use these directly.

Could you see either approach working? and if so, which would you recommend?
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Fwd: ajax push app - comet/gwt/continuations

2008-05-18 Thread Emil Ong
On Sun, May 18, 2008 at 09:34:22PM +, jdk head wrote:
 Thanks, Emil, for the quick response
 
 When resin's comet suspends the thread, does it not count against the
 thread-max setting?  If not, that's great.

Yes, that's right.  It may be better to think of it in this way, though:
the Comet servlet uses the threads from the same thread pool as
everything else.  When it suspends, the threads go back into the pool.
When it resumes, it takes a thread from the pool.  No additional threads
are being allocated for Comet either dynamically or statically.

 We're pretty deeply committed to GWT right now - lots of implementation
 already, so I need to figure out a good way to get GWT to work with resin
 comet.  I can think of two possibilities to try:

I think GWT is a great choice.  I hope I didn't imply that I don't think
it's suitable.  It would be great if it had better Comet support, but
AFAIK, it's not there yet.

 1) make inital calls to GWT's RemoteServiceServlet, and pass its
 getThreadLocalRequest() and getThreadLocalResponse() into the comet servlet
 service() and resume().  Then hope the suspension and everything still works 
 ok

I'd have to check on this, but I don't think it would work.  That is, I
don't think you can pass a thread from a normal servlet to a Comet
servlet.  Also, I'm not sure what the semantics would be on the client
even if you could.

 2) make initial calls to a resin comet servlet, then dig into the GWT source
 and figure out what classes are doing the serialization of the RPC objects. 
 Have the comet servlet use these directly.

This is more on track, but the problem still remains that you have to
decode an RPC request on the client.  This actually isn't that hard, but
it requires hacking the GWT compiler a bit.  All you really need to do
is create a stable name for methods on the JavaScript side, since GWT
will mangle them in its standard and obscure modes.  Then you can just
send down JavaScript invocations of those methods.

 Could you see either approach working? and if so, which would you recommend?

There has been some work on GWT and Comet. I've just glanced at these,
so I can't give detailed comments.

This one is a bit dated, but it might still work:
http://www.jroller.com/masini/entry/a_comet_implementation_for_google

This one uses Jetty, so I'm not sure if it would work with Resin.
http://docs.codehaus.org/display/JETTY/GWT

Best,
Emil



Emil Ong
Chief Evangelist
Caucho Technology, Inc.
Tel. (858) 456-0300
mailto:[EMAIL PROTECTED]
http://blog.caucho.com/

Caucho: Reliable Open Source
-- Resin: application server
-- Quercus: PHP in Java
-- Hessian Web Services


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] Fwd: ajax push app - comet/gwt/continuations

2008-05-17 Thread jdk head
Hi y'all,

For an ajax push app...

Has anyone had any luck with:
A) integrating resin's comet support with GWT's server side - extends
*com.google.gwt.user.server.rpc.RemoteServiceServlet
?
*

   - given they both seem to be servlet wrappers, any way can they play nice
   together?

B) resin / continuations?
C) resin comet / continuations?

Maybe comet would be all that's needed.  My main concern is trying to not
chew up all the threads.

Also, any advice on the best way to configure resin to handle a lot of
sleeping concurrent requests?  Seemingly continuations might help out with
the threads part, but what about the tcp connections?  Best handled with
mod_caucho or resin direct?

Thanks, and push on!
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest