Todd Eisemann wrote: > THANKS again Alek > > That makes sense to me... I can understand why the factories and > providers are not thread safe. > > But I do think the static helper WSIFUtils and the isJavaKeyword() > private method could be made BOTH faster performance wise, and > threadsafe - simply by initializing the keywordmap in a static > initializer. > good point - could you open a jira issue for it and let see what can be done to have this fixed (you will need to create JIRA account if you do not have it already): http://issues.apache.org/jira/browse/WSIF
thanks, alek > 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) > > THANKS > > > -----Original Message----- > From: Aleksander Slominski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 5:44 PM > To: [email protected] > Subject: Re: Worried about multithreading with WSIF > (ConcurrentModificationException) > > 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]
