11:03 p.m.
1. Messaging needs a working multiplexed transport.
There is currently a multiplex transport (as Ovidiu noted) and how it works under the hood
is explained at
(http://labs.jboss.com/portal/jbossremoting/docs/multiplex/multiplex.html). Its
performance is not great (see
http://labs.jboss.com/portal/jbossremoting/docs/benchmark/performance_ben... for
comparison benchmarks). Ron can probably
I have been looking at Mladen's MUX project as another option for a multiplex
transport to remoting. However, it does not automatically handle calling back over the
same physical connection, so this behavior will need to either be added within the MUX
project or on top of it. I have not done much testing with the MUX project other than
some simple coding to see how it works/behaves. No idea on performance, but know that
Mladen says he still wants some more time to work on it before he feel comfortable doing a
GA release for it.
2. Remoting uses a server-side blocking thread-per-connection model.
So guess would be good to cover scenarios and best approaches for them. The first
scenario would be having a limited set (in the low hundreds) of clients that each
regularly make invocations. In this scenario, having optimal throughput is probably the
desired behavior and the current remoting code is designed for this. At the other end of
the spectrum would be having a large number of clients (in the thousands) that each make
periodic requests (meaning is not in tight loop that continually makes invocations). The
best scenario for this is to use non-blocking i/o. The main reason for this is if use
blocking i/o (besides running out of resources) will have thread per request and will be
slow as balls because of all the thread context switching for all the concurrent requests.
Then there are the scenarios in between (btw can add config so that remoting does not
hold connection after invocation on the server side so that will free worker threads
faster, which I am pretty sure is already in jira).
As Ovidiu said, I am looking into adding NIO (and APR) currently. However, I don't
want anyone thinking that will see a performance gain from the NIO transport until reach a
certain threshold of clients (probably somewhere between 300-700, but don't have
anything concrete on this yet). Of course, there are still a ton a factors that influence
this as well such as number of cpus, jvm, network, etc.
3. Remoting uses a client-side blocking request-response invocation model.
Have made the code changes (for jira issue http://jira.jboss.com/jira/browse/JBREM-548) so
that if doing one-way invocations, only the request ever gets written to the wire and that
thread on the client returns immediately after the write. On the server side, it never
writes the response back to client.
Probably good to have better definition of what asynchronous means. There are a lot of
places the term can be used. At a high level in the call stack, can just mean using a
future model to make call and wait for a response to come back at later point in time (or
just a callback on a different thread at later point in time). At lowest level, could be
talking about only writing on the wire and not waiting for response off the wire. Lots of
places term can be used in between the high and low level.
4. Messaging needs the ability to send unformatted data on the wire.
It is possible to send and receive raw payload data using remoting where is not wrapped in
the remoting InvocationRequest/InvocationResponse using configuration per request.
However, the behavior of doing this is not consistent over all the current transports.
Also, sending raw data will prevent a lot of the extra remoting features from being used
as internal remoting metadata is included in the InvocationRequest/InvocationResponse
wrappers.
Another issue is the types of streams being given to the marshalling layer being
inconsistent across the different transports (this is covered in
http://jira.jboss.com/jira/browse/JBREM-597). My preference is to only send the raw
OutputStream/InputStream to the marshalling layer and allow the Marshaller/UnMarshaller
implementations decide on what type of streams to wrap around the raw ones passed in (if
any).
There is certainly a lot of re-working that can be done in this general area and hoping
the efforts for NIO transport will help bring these out.
As for AMQP, I don't now anything about it, so can?t comment.
As for remoting and its purpose, it is exactly as Juha stated which is to provide a
remoting platform that other JEMS projects can use (but imo should be by choice). I have
tried my best to do this in a way that any new feature or implementation does not
negatively impact any other project that may be using remoting. The only jira issue
derived from the messaging project that has been rejected is
http://jira.jboss.com/jira/browse/JBREM-371, which I couldn't do per previous
sentence. It is my guess that at least a third of the development effort for remoting
this year has been related to supporting the messaging project (which has all been good
for the remoting project in general). The remoting team is myself and Ron Sigal (who is
now splitting development time between remoting and messaging). There are 51 remaining
open issues for the next remoting release (plus many external ones related to remoting).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978948#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...