Shash: +1 here too, and this is a very important fix Eric has found - one I thought we'd dealt with but definitely haven't.
Eric, do you already have a sourceforge account? If so, we'll get you set up with read/write access right away. Thanks for finding and fixing this! Mike On Thu, 09 Oct 2003 08:31:30 -0500 "Sasvata (Shash) Chatterjee" <[EMAIL PROTECTED]> wrote: > All, > > 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 Michael Nash JGlobal Ltd. http://www.jglobal.com Bahamas Commerce and Trade http://www.bahamascommerce.com http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
