Hi, anonymous wrote : The current default policy that we've agreed on for ordered execution is: Each request on a single Client instance that happens-after a previous request, will also happen-after the previous request on the server side (maybe not in the same thread though). That is nice. I would suggest a javadoc on send,invoke and sendOneWay saying this. That means ordered execution need to be handled by the client. It is fine for me however I would like to serialize execution per (session) client. What is the API to get the current (session) client? anonymous wrote : Also, this means that (since you're using context.execute() to run a background task), it's possible that the "Executing..." lines will be out of order; this is not something I plan to change (though there are some utility classes that can help if you want ordering, like OrderedExecutor). About this, I suggest a API change if it is possible. I would something like this: context.sendReply(context.execute(new Callable<Integer>() { | @Override | public int call() { | System.out.println("Executing... " + request); | return value++; | } | })); | anonymous wrote : Now the fact that "Remote: 4" comes before "Remote: 3" is just a plain old bug. :-) As soon as I get marshaling fixed up I'll come back to it - I think we just haven't integrated any ordering code yet. As you said if execution order is not guaranteed then this behavior isn't wrong unless only one thread executes the handleRequest. anonymous wrote : What problem are you having? You should have been able to just check out trunk and type "ant", and all dependencies would be downloaded for you. Can you start a separate topic for this? One of the dependencies wasn't downloading with the "all" target. But my main concern was with eclipse integration. The projects couldn't be built with it. I had to create a standalone sample project and import the jars files to execute (and I didn't know what jar are needed, e.g. jboss common log). I will open another thread latter when I get home. anonymous wrote : No, XNIO 1.1.0 will be required (it's still in development but there's an API snapshot which is used for the build). Is the xnio trunk working for it or just the jar that you download in the ant build? anonymous wrote : Hm, that's not good. I'll have to come up with a slightly different executor strategy for these things. Care to file a bug (set "fix for" to 3.0.0.Beta1)? :-) I will do it. But could you explain what were you trying to accomplish? I saw a wiki entry (or was it the docs of 2.5.0.ga) that when the system is under load it rejects some messages, is that what is the exception is for? If it is, how could I turn this off, because my use case I need delivery guarantee and I message lost means a failure in transport. One more thing :) Is TCP transport ready? If it is, can you post a sample using it :P I tried looking the M2 sample but the API changed and I could not find how to do it. Tnx and congrats for the project. Very very good. Hope closures make java 7 and it will look sparkling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176829#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...