Hi Conor, That's pretty much what I implemented. I was wondering if you had done anything more robust than what I already had :)
Steve... >>> [EMAIL PROTECTED] 07/31/03 01:34PM >>> actually there's not much to post as it a simple prototype at the moment to validate the impact of a full blown cache in the future. For the test I simply implemented the service locator as a singleton and set each of the stubs as a member variable in the locator. The first call to retrieve a service (stub) via the locator initializes the appropriate stub if it's null. Pretty simple and definitely not thread safe at the moment but it validates the point we were looking into. If you need more info I can send it onto you directly. Conor. -----Original Message----- From: Steve Earl [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 6:27 PM To: [EMAIL PROTECTED] Subject: Re: Stub Caching Would you mind posting some of your caching code? Steve... >>> [EMAIL PROTECTED] 07/30/03 16:45 PM >>> Hi, I just wanted to share some insight we have had with some performance testing of web services sitting on top of Axis. Based on the initial analysis carried out the majority of the time spent on the client side when invoking web services is in the method YOUR_SERVICE_STUB.createCall(). This in turn calls Call.regiterTypeMapping() (org.apache.axis.client.Call) where the time is actually spent. The method createCall() is autogenerated by WSDL2Java. If you look at the comments you will notice that the stub is intended to be cached but you must implement the caching of stubs however you see fit for your application. Under load in our tests we saw performance improvements from approximately 28 seconds to 1.5 seconds by caching the stubs. Conor.
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Earl, Steve TEL;WORK:(616) 233-3905 ORG:;MIS TEL;PREF;FAX:(616) 456-5648 EMAIL;WORK;PREF;NGW:[EMAIL PROTECTED] N:Earl;Steve TITLE:Senior Technologist END:VCARD
