servlet transport implementation

[ataylor]

At the minute I'm still adding some jboss as 5 integration so i can run this, but in essence this is how i see it working.

On the client side we use the netty http transport to send messages to the servlet, there'll probably be changes needed around keep alive etc and I'll also use session id's in the Http requests.

On the server side we have 2 main components.

An HttpSessionListener which we use to maintain actual INVM connections. This means we can tidy up connections when sessions timeout. We can also control the timeout and have it configurable in the usual transport manner. Th einvm connection will be added to th eservlet context making it available in the servlet

The servlet itself. All this basically does is forward the content to th einvm connection and return any responses available.

Again, this will support true 1 - 1 request/response cardinality and I'll add support for both keep alive and separate requests.

[gaohoward]

I'm handling servlet support in JBM 1.4 and the JBoss remoting provides much support for sevlet handling. It should be better if netty can provide the support so that we don't have to handle the details in JBM.

[ataylor]

It should be better if netty can provide the support so that we don't have to handle the details in JBM.

That would be nice but we need this asap and netty only has a basic http implementation.

[clebert.suconic]

IMO the servlet package should be in org.jboss.messaging.integration.transports.servlet, or maybe just org.jboss.messaging.integration.servlet

instead of org.jboss.messaging.servlet

[ataylor]

IMO the servlet package should be in org.jboss.messaging.integration.transports.servlet, or maybe just org.jboss.messaging.integration.servlet

instead of org.jboss.messaging.servlet

I was going to do that originally, but its compiled separately as it goes within the war i thought some separation would be best.

[timfox]

"ataylor" wrote:

It should be better if netty can provide the support so that we don't have to handle the details in JBM.

That would be nice but we need this asap and netty only has a basic http implementation.

True we need this ASAP, but the work is a generic piece of work (Netty Servlet proxy), so it can still be done in the Netty project, even if the work is completed by a JBM team member.

[ataylor]

here's a bit more of a detailed explanation to how this will work. This will be implemented in netty as discussed in irc.

A ServletContextListener will create a ClientBootstrap on startup. This will be configured via properties, probably read in from a config file with some sensible defaults. This will be added as an attribute to the ServletTransport. It would be cool if netty had an invm client bootstrap to use however in the absence of this it will be a normal socket connection. Trustin, currently would there be any way of doing this invm?

An HttpSessionListener will be used to create a connection for each session. Since netty doesn't support cookies at the minute we will have to manually check the headers to pull out the session id and add it as a parameter for all further requests. Also at this point we'll set the pipeline factory before creating the connection. a seperate instance of a 'ServletChannelHandler will be set for each connection. Both the Channel and the ServletChannelhandler will be added to the session as attributes.

The ServletChannelHandler will work 2 ways. On MessageReceived it will either 1) store the received buffers to be returned by the next http request (polling) or 2) write directly to the ServletOutputStream (streaming).

The Servlet itself will decode the http request body and forward it via the channel previously set on the session. It will then set the appropriate headers on the response and return as the body any awaiting responses if using the polling method.

From a client side we'll be able to reuse most of what we already have. maybe just a few changes for using sessions and for streaming.

Trustin, how would you like me to package the servlet classes etc. Also i'll include some sample web.xml configurations etc so where should i put these?

[timfox]

"ataylor" wrote:
here's a bit more of a detailed explanation to how this will work. This will be implemented in netty as discussed in irc.

A ServletContextListener will create a ClientBootstrap on startup. This will be configured via properties, probably read in from a config file with some sensible defaults. This will be added as an attribute to the ServletTransport. It would be cool if netty had an invm client bootstrap to use however in the absence of this it will be a normal socket connection. Trustin, currently would there be any way of doing this invm?

I would like to hear Trustin's view on this before committing to this.

Having one TCP connection proxying to another TCP connection might introduce unnacceptable latency.

Trustin- what do you think?

[trustin]

Sorry for the late response. I was busy with releasing Netty 3.1.0.ALPHA3. :-)

"ataylor" wrote:
A ServletContextListener will create a ClientBootstrap on startup. This will be configured via properties, probably read in from a config file with some sensible defaults. This will be added as an attribute to the ServletTransport. It would be cool if netty had an invm client bootstrap to use however in the absence of this it will be a normal socket connection. Trustin, currently would there be any way of doing this invm?

What does 'invm' transport refer to here? Do you want Netty to add in-vm transport, or do you want Netty can talk to the in-vm transport that JBM uses internally? The only interfaces that you need to implement is 'ChannelFactory' and 'Channel', so it's not a big deal to implement a bridge between JBM invm transport and Netty. ClientBootstrap should work with any ChannelFactory implementation.

"ataylor" wrote:
An HttpSessionListener will be used to create a connection for each session. Since netty doesn't support cookies at the minute we will have to manually check the headers to pull out the session id and add it as a parameter for all further requests.

I think Netty needs to provide a cookie encoder / decoder as we did for query strings.

"ataylor" wrote:
Also at this point we'll set the pipeline factory before creating the connection. a seperate instance of a 'ServletChannelHandler will be set for each connection. Both the Channel and the ServletChannelhandler will be added to the session as attributes.

The ServletChannelHandler will work 2 ways. On MessageReceived it will either 1) store the received buffers to be returned by the next http request (polling) or 2) write directly to the ServletOutputStream (streaming).

The Servlet itself will decode the http request body and forward it via the channel previously set on the session. It will then set the appropriate headers on the response and return as the body any awaiting responses if using the polling method.

I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.

"ataylor" wrote:
From a client side we'll be able to reuse most of what we already have. maybe just a few changes for using sessions and for streaming.

Trustin, how would you like me to package the servlet classes etc. Also i'll include some sample web.xml configurations etc so where should i put these?

It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-)

[ataylor]

What does 'invm' transport refer to here? Do you want Netty to add in-vm transport, or do you want Netty can talk to the in-vm transport that JBM uses internally? The only interfaces that you need to implement is 'ChannelFactory' and 'Channel', so it's not a big deal to implement a bridge between JBM invm transport and Netty. ClientBootstrap should work with any ChannelFactory implementation.

By invm transport I mean rather than writing to a socket channel use an invm channel and pass the buffers directly thus avoiding the latency Tim was talking about. I guess you've answered my question there isn't. So I guess I need to provide a new implementation of ChannelFactory and Channel which can do this?

I think Netty needs to provide a cookie encoder / decoder as we did for query strings.

Ok, this should be pretty simple.

I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.

No, JBM will only receive the http response, it won't talk to netty.

It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-)

Ok, that will give it seperation and make it easier to deploy. what would you like to call the sub project?

[timfox]

"trustin" wrote:

I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.

The idea, is it's a *generic* Netty proxy over HTTP, not something specific to JBM. Therefore it can't talk to JBM directly or it would be limited to use only with JBM, and couldn't live in the Netty source tree.

[ataylor]

Trustin, Ive created a branch https://svn.jboss.org/repos/netty/branches/invm/. I've done a quick and rough proof of concept for an implementation of Channel and ChannelFactory that the servlet transport will use. Theres an InvmExample that you can run.

Its a bit untidy and theres still a bit missing but it should give you an indication of how it shoud work. Let me know your thoughts?

[trustin]

"ataylor" wrote:

"trustin" wrote:
It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-)

Ok, that will give it seperation and make it easier to deploy. what would you like to call the sub project?

http-tunnel, named after stunnel (http://www.stunnel.org/). WDYT?

[trustin]

"timfox" wrote:

"trustin" wrote:

I understood how it works, but out of curiosity, why does the Servlet need to talk to JBM via Netty? Isn't it just enough for the Servlet to talk to JBM directly? Perhaps I am missing out something.

The idea, is it's a *generic* Netty proxy over HTTP, not something specific to JBM. Therefore it can't talk to JBM directly or it would be limited to use only with JBM, and couldn't live in the Netty source tree.

Now I got the point. Thanks for clarification!

[trustin]

"ataylor" wrote:
Trustin, Ive created a branch https://svn.jboss.org/repos/netty/branches/invm/. I've done a quick and rough proof of concept for an implementation of Channel and ChannelFactory that the servlet transport will use. Theres an InvmExample that you can run.

Its a bit untidy and theres still a bit missing but it should give you an indication of how it shoud work. Let me know your thoughts?

OK. Let me review it and get back to you. :-)