Hi Ryan,
Well, we haven't been able to reproduce it with Mule either yet, else
I might have a better idea of what was going on! That said, given it
appears selector logging is failing, the only non-grizzly thing it
could potentially be, is the JUL->Log4J logging bridge.
Because logging fails, we don't even have any root cause exception or
stack-trace when the selector dies other than "ClassDefNotFound". I'm
assuming it's the same issue as described in the posts I linked to,
though, this would explain why I see no logs. BTW this is grizzly
2.3.36.
I am clueless as to why, in runtime, this exception would suddenly be
thrown :-( For now i've added a log of system out logging, to see if
that gives us any more insight, but if you have any ideas please let
me know..
Dan
On 19 December 2016 at 07:55, Ryan Lubke <ryan.lubke_at_oracle.com> wrote:
> Sorry for the delay. I've never seen anything like this particular error
> case. Is it possible to reproduce outside of Mule?
>
> Daniel Feist
> December 14, 2016 at 16:23
> Hi Alexey/Ryan,
>
> Seeing a really weird issue where, in runtime, sometimes after 1wk or
> more, NoClassDefFoundError errors are being thrown causing selectors
> thread to exit in some cases, and worker threads to fail in other
> cases.
>
> Here are a couple of reports of when it's happened in a worker thread:
> -
> http://stackoverflow.com/questions/40779193/mule-http-listener-thread-cant-resolve-org-glassfish-grizzly-localization-logme
> - https://www.mulesoft.org/jira/browse/MULE-10222
>
> It also happens in selector thread sometimes too, resulting in simply
> the following, curiously with no log output whatsoever.
>
> Exception: java.lang.NoClassDefFoundError thrown from the
> UncaughtExceptionHandler in thread "grizzly.selector(2)"
>
> Given there is no log output this also suggests an issue with
> LogMessages here too. From a class-loading perspective, everything is
> in the same classloader with no runtime changes being made.
>
> Any thoughts at all?
>
> Dan
>
>