Hm. No, it doesn't use WSS4J -- can't speak to multi-threading on that. The current use is 'internal', so no security required, yet. I'd say set it up and run some load tests -- it'll probably be better than speculation, and you were going to load test the system anyway, right? ;) Should be pretty easy to prototype, although you might want to simulate some long-running transactions or something just to make your tests interesting.
Sorry not more helpful, Chris -----Original Message----- From: Ron Reynolds [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 15:39 To: [email protected] Subject: RE: Is generated client stub meant to be used as shared service? does it use WSS4J, tho? i seem to remember reading a thread there that there may be thread-safety issues (tho those might have been server-side thread-safety issues - which is even worse...) perhaps a pool approach would work well instead of a per-thread approach. thankfully my clients are web-apps (built-in thread-pooling) and in-house relatively-low-load web-apps at that. > > 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 >> >> > > >
