Matthias247 / jawampa

Web Application Messaging Protocol (WAMP v2) support for Java
Apache License 2.0
148 stars 56 forks source link

Make transport pluggable #8

Closed nilskp closed 9 years ago

nilskp commented 9 years ago

Not sure if this is already possible, but it should be fairly easy to remove any hard Netty dependencies and instead have the transport be pluggable.

Matthias247 commented 9 years ago

As @fasar already asked the same thing I will copy the response below:

Initially I started like what you like to do now - with making the transport layer pluggable and having the client and router classes independent of Netty. However I then discovered that it made more trouble than I thought it was worth it - so I decided with hardwiring it to Netty.

The problems do not necessarily come from unifying the interface - that's quit simple. What is hard is that most I/O frameworks also have their own threading model and their own pipeline model. E.g. Netty uses multiple singlethreaded eventloops in parallel - most times I stay in a thread but for the Router there is a hop. Play (and Akka in general) work different with using the Actor model. Some Frameworks will expect a direct response to a request, other will allow to send it asynchronously. For some a send will be a blocking operation, for others it will be non-blocking but will still happen immediatly, and for the last group it will be non-blocking and the actual action will be deferred. And plugging the WampRouter on top of a Netty HTTP server so that it can run concurrently with normal HTTP on the same port might require a different model than running it concurrently with a Play HTTP provider.

Building in abstraction layers would also make some optimizations no longer possible that - e.g. more data would need to be copied (because some transports might mutate them later), more scheduler/executor hopping would be necessary and the optimized data structures from Netty could not longer be used.

Therefore I decided to avoid the extra complexity and just to go the Netty only road. I still think porting the whole thing on top of another layer would be easier than to provide a clean layered approach with pluggable transports.

fasar commented 9 years ago

Hello,

I've the same problem as you @nilskp. I've do an effort to remove netty dependency. The forked project is located at : https://github.com/fasar/jawampa/tree/parser

Be careful, this is the branch parser of jawampa.

This fork is less clean than @Matthias247 jawampa. It has some unit test to understand. I plan to add some javadoc.

++, Fabien.

nilskp commented 9 years ago

@Matthias247 That makes sense. I think you could have made the assumption that the transport layer must always be async, since this is websockets. This might simplify things. Regarding optimizations, that's without a doubt true, as abstractions always incur such costs. The only issue I see with your approach is that you've painted your project into a very small corner for usage, since most deployments are probably already running inside some other container. But if that's the scope, then so be it.

@fasar Looks like just the routing module, which is exactly what is interesting here. Too bad a fork is necessary though.