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 <[email protected]> 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!
>
