Todd Eisemann wrote: > THANKS Alek! > > This is a big help. > > So far, I've just been a WSIF user. And have found 2 small thread > synch problems. > > If I were to take the WSIF source, modify it to fix these thread safety > issues, get all the regression testers (I assume there is a Junit test > suite) , then do you think I could contribute these changes and they > would be considered for inclusion in a future release? > that would be very deep change and would probably break existing WSIF providers (see below) so that would require careful discussion of all pros and cons. > Or is the WSIF community so committed to WSIF NOT being thread safe - so > that you would not accept such contributions > believe it or not but this is actually a feature and performance is main reason why stubs generally are not multi thread safe - avoiding synchronization allows for not only better performance but also makes for deadlocks free code and better scalability ...
generally speaking making sure that wsif factories are thread safe would be very useful (there was some concerns what exactly in API it is and how custom factories should behave) but i am afraid that making actual "stubs" (such as WSIFPort) is hard as underlying code in providers is not thread safe so extra synchronization would be required (or other tricks to not block but allow multiple threads ot use the same stub or close of it). HTH, alek > Let me know your thoughts. > THANKS > > -----Original Message----- > From: Aleksander Slominski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 4:11 PM > To: [email protected] > Subject: Re: Worried about multithreading with WSIF > (ConcurrentModificationException) > > Todd Eisemann wrote: > >> Hello all >> >> We are wsif users and incorporate it in our production applications. >> Recently, we've run into 2 concurrency problems with WSIF Version 2.0. >> >> The latest error is >> >> 1| java.util.ConcurrentModificationException: concurrent access to >> HashMap attempted by Thread[WebContainer : 3,5,main] >> >> 1| at java.util.HashMap.onEntry(HashMap.java(Compiled Code)) >> >> 1| at java.util.HashMap.transfer(HashMap.java(Compiled Code)) >> >> 1| at java.util.HashMap.resize(HashMap.java(Inlined Compiled Code)) >> >> 1| at java.util.HashMap.addEntry(HashMap.java(Compiled Code)) >> >> 1| at java.util.HashMap.put(HashMap.java(Compiled Code)) >> >> 1| at >> > org.apache.wsif.util.WSIFUtils.isJavaKeyword(WSIFUtils.java:1350) > >> 1| at >> >> > org.apache.wsif.util.WSIFUtils.getJavaNameFromXMLName(WSIFUtils.java:971 > ) > >> 1| at >> >> > org.apache.wsif.util.WSIFUtils.getPackageNameFromXMLName(WSIFUtils.java: > 988) > >> 1| at >> >> > org.apache.wsif.util.WSIFUtils.getPackageNameFromNamespaceURI(WSIFUtils. > java:890) > >> I can see how this can happen in the isJavaKeyword() method as the >> static HashMap kewordmap get re-initialized every call. >> >> Why not initiatialize that HashMap just once in a static >> > initializer???? > >> But, this is the second thread synchronization problem that we have >> stumbled across. The other was in the constructor for >> WSIFDynamicProvider_ApacheSOAP(). >> >> I worry that there may be other multithreading problems in WSIF that >> we just have not come across in our load test and production >> environments. >> >> Is WSIF 2.0 considered thread safe? >> >> > it never was considered thread safe AFIACR - WSIF uses typically stubs > in providers and those are typically not thread safe > >> Are there any plans to improve WSIF for concurrency? >> >> > long time was some work considered to clarify exactly what is thread > safe (such as factories) and what not (such as WSIFPort which is > essentially stub derived from WSDL port and backed up by provider) > > HTH, > > alek > > -- The best way to predict the future is to invent it - Alan Kay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
