Eric has submitted several patches over time. I propose that he be made a committer a Keel. If not, I'll include the changes.
+1 from me.
Eric, one of the plans we have for the immediate feature (after 2.0) is to allow context-sharing across multiple servers and have load-balancing/failover from any of the clients. This will work only for the distibuted server/client case, not when embedded directly in the same JVM/webapp. Keep that in mind when managing the client/server lists.
Thanks for the changes.
Shash
Eric Simmerman wrote:
Keelers, While performance testing a webservice I built on top of Keel, I noticed that the current (anon cvs) KeelDirectServer is not multithreaded at the request processing level. The Instrumentation Client demonstrated this to me in dramatic fashion after I added a counter to the execute() method on my Model and its graph over time never rose above one! A quick look at the code and sure enough…KeelRequests are processed one at a time. The server spawns a new KeelServerThread for each request, but then it calls join and waits for the result.
I’ve patched the files necessary to multi-thread request processing and have reaped some significant performance boosts using the DirectServer. I'm not currently able to create a CVS patch, as Anon CVS access has been unavailable lately. Please let me know how I can submit my changes. I've written a quick summary below.
Changes:
1) Currently, our ClientConnectors are not thread-safe. The client list maintained in AbstractClientConnector is not populated in a thread-safe manner. This can easily result in the creation of multiple DirectClients and therefore multiple DirectServers if my AxisClient services two simultaneous requests after startup. So, I patched AbstractClientConnector to insure that the client list is populated in a threadsafe manner. All ClientConnectors in the JVM will now access the same thread-safe client list. Given the current client creation logic, this will insure that we will populate the list with at most one DirectClient and therefore only spawn one KeelDirectServer.
2) KeelClientDirect isn't threadsafe, because it can potentially create multiple KeelStarters, which will result in multiple KeelDirectServers and Avalon Containers. I synchronized the creation of a single KeelStarter.
3) KeelStarter didn't instantiate KeelDirectServer in a thread-safe manner. I synched this creation as well.
So far, we've made everything on the "client" side thread-safe. Now, I need to multi-thread request processing in the KeelDirectServer itself.
4) I created a simple subclass of Thread as an inner class named MultiThreadedProcessor, and used it within KeelDirectServer's run method. As an inner class, it has access to the communication channels held in KeelDirectServer and can call the server's execute() method directly. So it doesn't have to hold much logic and simply serves as a threaded proxy.
5) The final change necessary is to insure that the requesting thread receives the proper response. To accomplish this, I took a page from JMS's book and simply included the response queue in the request. Each requesting thread creates its own response queue and pushes this onto the request queue along with the request.
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
