Why any JCA Resource Adapter's worker threads are harmless.

[Nitin Verma]

Hello,

XADisk can be deployed as a JCA 1.5 resource adapter. Some application
servers like Weblogic
have an extra-feature (though, it is not as part of the JavaEE spec)
of logging messages/warnings
when a thread (even if it is a JCA Worker thread) does not complete
itself within a configured amount of time. This time is called
StuckThreadMaxTime in case of Weblogic.

Such warnings often cause unnecessary confusion while using XADisk JCA
Resource Adapter with Weblogic. In this thread, I am copying the
conversation I had with a few other folks. I hope this can be useful
for someone coming across the same situation.

Thanks,
Nitin

[Nitin Verma]

First conversation:


Jaroslav (Question) - Normally, work which is run with WorkManager
should run simple job and return. If you need to run something in some
interval, it woud be better to use some timer service which calls
startWork for each execution. Starting works, which does not finish,
causes problems in weblogic. After some defined time, these threads
are marked as STUCK and weblogic kills them. This is reason for
creating <work-manager> element in weblogic-ra.xml, which has ignore-
stuck-threads set to true.

Myself (Response) - From the JCA spec, it is very common for Work
instances to keep running for lifetime of the JCA Adapter. The Stuck
threads facility from Weblogic can be seen as an additional feature.
XADisk uses both periodic and non-periodic work instances, so we won't
be able to use some timer service. In my opinion, solution of the
ignore-stuck-threads=true should be good enough and would allow us to
keep using the standard technology like JCA.

Jaroslav (Response) - Yes, this "super feature" with STUCK threads is
two-edged. It allows server to kill some threads which are e.g.
deadlocked, but for long-running transactions or works it is like the
mother-in-law. Again I agree, weblogic-ra.xml is the right place to
keep it working for weblogic.

[Nitin Verma]

Second Conversation (websphere):

Phil (Question) - I guess that Websphere does not like the threads to
be long running, even if they are not blocking (I can see that the
threads are just
sleeping waiting for the next event to process…). Unfortunately,
Websphere does not allow configuring the ThreadMonitor to exclude
certain threads, although I can turn the monitor off (but then it
won’t detect any hung threads at all).

I just wanted to get you input on whether XADisk is behaving in a way
that is compliant with the JCA specs and Websphere is being picky,
or is there some other way that the XADisk threads could be written
(polling perhaps) that would stop Websphere complaining about them?

Myself (Response) - "....here is some text from JCA specification
(1.5) (Chapter on Work Management) to support the use of long running
work instances...

"Such resource adapters may use threads to listen to network
endpoints, process incoming data, communicate with a network peer, do
its internal work, or dispatch calls to application components."

So, XADisk is doing work in a JCA compliant way and any JEE server
should support (if not directly, using a configuration property) long
running (or waiting) work instances.