Eric,
These changes are excellent. Santanu and I had made some changes to the
client side classes on the 1.0 branch to make keel more friendly in a
multithreaded environment, but our changes weren't nearly as complete as
what you're describing here, and they also didn't make it to the current
head because a lot of the code had been significantly refactored from
the 1.0 branch.
Thank you for making the changes, including (and especially) making the
KeelDirectServer multi-threaded. This was a real scalability limit to
using the direct server, which you have now addressed.
I also say +1 on giving Eric access to commit to CVS.
-Phil
On Thu, 2003-10-09 at 02:39, 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 enoughKeelRequests 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.
>
> Ive 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.
>
> -Eric
>
>
>
>
> http://keelframework.org/documentation
> Keelgroup mailing list
> [EMAIL PROTECTED]
> http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
>
http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
