of course, I can test your new version on my environment.
I have created on my site lot of hot fixes, to make DWR usable as powerful reverse-ajax library. Those fixes are outside the DWR, so my code will not help you. But, I want to write here, what I think DWR should change to be perfect library.
Problem 1. Threading:
You are right, there should be some separate thread pool, which will be used for sending messages into conduits. One fixed size thread pool, for all the ScriptSessions. And while sending there should be exactly one thread from thread pool doing the job for one ScriptSession. And every time some other thread calls ScriptSession.addScript, or ScriptSession.addConduit it just saves it into ScriptSession, and thread pool does the send job. Threads in the thread pool should have max sending time. After they hang for let say 5 sec, they should be killed.
Problem 2. Message counting
This way, I never lose incoming message from server. And always push them into browser in good order. For example, if I receive messages like 1,2,3,5 and 4th message is lost. Client executes messages 1,2,3 than sends array of indexes[1,2,3, 5] to the server and server sends again no: 4 and deletes 1,2,3,5 from his history stack. Client is waiting for no: 4. When no.4 is received, client executes messages: 4,5. It works perfect.
The only downside is, that I have to send extra message from client with array of indexes of received messages. It would be much better, if DWR does it silently, by adding this call to commonly used HttpRequests.
Problem 3. Lost HttpRequests + ordering
My users sometimes complain, that their client is stacked and stopped to work. This is caused by requests that were not delivered correctly to the server. Of course, client can detect if request delivery failed. What I am missing is option for must deliver and keep order. I mean if it fails, it should be send again and again and again. I am not sure, how this is in in DWR, I am partly solving this on my site. And Ordering is not solved for sure in DWR.
I did not fix this last problem yet correctly on my side. But I miss it.
I know, that there are web pages, that does not care, about ordering of messages, or even losing some messages. I think there should be such option in DWR, to set up mustDeliver = true , keepOrder=true. In fact, once you want to solve problem with duplicate messages received, you have to add identifier to the messages. And than, the ordering and must delivery options are not big problem to implement.
Problem 4. WebSocket
WebSocket is future of web. Why to use tricky hacks, if it can be easily done by WebSocket? DWR is awesome, because of Js2Java and Java2Js object mapping. But future is in WebSocket. I am using DWR for IE, FireFox and in Chrome, I am using WebSocket. Since DWR is so cool, I am using DWR for client->server communication. But when there is an option for WebSocket, I am using websocket for Server->Client communication. I simply convert my Java message by DWR library into String. And than I send that string via WebSocket. WebSockets are easy to implement, why not to use them if there is such option? If you make WebSocket native in DWR, you can use it for both site communication Client->Server and Server->Client. This way, DWR would be very attractive and powerful.