Hi Vjeran, I'm not setting the username/password, nor using attachments (although I'll have to use attachments soon). If I had to solve these problems, I'd either go with a thread local or an object pool: creating stub objects is fairly costly. ThreadLocal is easy to implement, object pool is more efficient in use of objects (a Tomcat server might have a couple hundred threads sitting around...)
Chris -----Original Message----- From: Vjeran Marcinko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 20:47 To: [email protected] Subject: Re: Is generated client stub meant to be used as shared service? Hello.... Is there some Axis developers around here to give ultimate answer to this question ? And Chris, how do you send username/password, or attachments with your call when using such shared stub, because these are set on stub instance which is shared so you are not allowed to do it in such scenario ? One thing that comes on my mind is to bind username/password to ThreadLocal, and use it inside some handler (or whatever) which has access to Call instance created secifically for this request. IS it good idea ? Regards, Vjeran ----- Original Message ----- From: "Ebert, Chris" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, November 02, 2005 11:32 PM Subject: RE: Is generated client stub meant to be used as shared service? I ran a test at one point with multiple threads all running commands through a single instance of the stub. It ran OK with Axis 1.2. I'm using it currently in production without a whole lot of load -- no troubles so far. Creating a stub has the side effect of loading *all* the jar files on the classpath (searching the metadata for some config. This causes a spike in memory which for me is bad.) I tried a couple of other tricks to get around this, but none seemed to work; using one instance of the stub does, however. Chris -----Original Message----- From: Ron Reynolds [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 12:57 To: [email protected] Subject: Re: Is generated client stub meant to be used as shared service? i wasn't sure about this either, but i also use the Stub._setProperty() to specify a user-name to the WSS4J handler so i couldn't have multiple threads using the same stub instance anyway so i wrapped it into a ThreadLocal and added it to my client-side util class: public class ClientUtils { /** holds the FreezerAPI object for the calling thread */ private static final ThreadLocal m_threadsFreezer = new ThreadLocal(); public static FreezerAPI getFreezerApi() throws MalformedURLException, ServiceException { FreezerAPI freezerApi = (FreezerAPI)m_threadsFreezer.get(); if (freezerApi == null) { FreezerWebServiceLocator locator = new FreezerWebServiceLocator(); if (m_freezerUrl == null) { m_freezerUrl = new URL(locator.getFreezerWSAddress()); } freezerApi = locator.getFreezerWS(m_freezerUrl); m_threadsFreezer.set(freezerApi); } return freezerApi; } public static FreezerAPI getFreezerApi(String loginName) throws MalformedURLException, ServiceException { FreezerAPI api = getFreezerApi(); setLoginName(api, loginName); return api; } public static void setLoginName(FreezerAPI api, String loginName) { ((Stub)api)._setProperty(WSHandlerConstants.USER, loginName); ((Stub)api)._setProperty(WSHandlerConstants.PW_CALLBACK_CLASS, new UserIdPWCallback()); } } that seemed to reach a good balance between performance (i.e., not having to create lots of stubs) and thread-safety. HTH. ................ron. > As said in subject - > Is WSDL2Java generated client stub meant to be used as thread-safe > shared service by multiple threads simultaneously, or is it meant to > be instantiated for each call ? > > -Vjeran
