Hi David! It's not a known issue. I had a short look into the code and the it happens at the following line: public Language resolveLanguage(String language) { Language answer; synchronized (languages) { // <- line 962 answer = languages.get(language);
// check if the language is singleton, if so return the shared instance if (answer instanceof IsSingleton) { boolean singleton = ((IsSingleton) answer).isSingleton(); if (singleton) { return answer; } } // language not known or not singleton, then use resolver answer = getLanguageResolver().resolveLanguage(language, this); if (answer != null) { languages.put(language, answer); } } } Can you raise a JIRA and attach a thread dump? Best, Christian On Mon, Apr 22, 2013 at 2:28 PM, David Godfrey <davidg...@gmail.com> wrote: > I am using Camel within a web-application running on WebSphere > Application Server v7. > > > I am using a Camel Timer with a 1 second poll cycle. Originally I was > using Camel 2.9.1, upgraded to 2.9.6 to see if that would make any > difference. > > Observed behaviour is that when run on Windows, all works perfectly > well. When running the same code on a Linux platform, I get a deadlock > in DefaultCamelContextImpl, as follows: > > [22/04/13 13:56:32:586 EEST] 0000001e ThreadMonitor W WSVR0605W: > Thread "Default : 5" (0000001b) has been active for 661957 > milliseconds and may be hung. There is/are 1 thread(s) in total in > the server that may be hung. > at > org.apache.camel.impl.DefaultCamelContext.resolveLanguage(DefaultCamelContext.java:962) > > Before I post any more detail information, code examples, etc...is > this a known problem? I searched as much as I could but couldn't find > more information. > > I also tweaked the config of WebSphere on the linux platform, for > example, allowing unlimited thread pool sizes to see if that made any > difference but it does not appear to do so. > > many thanks! >