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!
>

Reply via email to