Ok, I wrote a little byteman script to trace calls to EndpointAssociation.setEndpoint and EndpointAssociation.getEndpoint:
# rules to track calls to getEndpoint and setEndpoint in CXF code
#
RULE trace setEndpoint
CLASS EndpointAssociation
METHOD setEndpoint
IF TRUE
DO trace("foo", "setEndpoint(" + $1.getName() + ")\n" + formatStack())
ENDRULE
RULE trace getEndpoint
CLASS EndpointAssociation
METHOD getEndpoint
AT RETURN
IF TRUE
DO trace("foo", "getEndpoint() ==> " + $!.getName() + "\n" + formatStack())
ENDRULE
When I ran my tests with this script installed I got a few cases where successive gets and sets were using different endpoints. Here is a dump of the (filtered and reformatted) trace output:
setEndpoint(Interop11ATParticipantService)
Stack trace for thread http-127.0.0.1-8080-3
getEndpoint() ==> Interop11ATParticipantService
Stack trace for thread default-workqueue-1 // n.b. worker 1 from participant executor
setEndpoint(ActivationService)
Stack trace for thread http-127.0.0.1-8080-4
getEndpoint() ==> ActivationService
Stack trace for thread http-127.0.0.1-8080-4
setEndpoint(RegistrationService)
Stack trace for thread http-127.0.0.1-8080-4
getEndpoint() ==> RegistrationService
Stack trace for thread http-127.0.0.1-8080-4
setEndpoint(CompletionCoordinator)
Stack trace for thread http-127.0.0.1-8080-4
getEndpoint() ==> CompletionCoordinator
Stack trace for thread default-workqueue-1
setEndpoint(CompletionInitiator)
Stack trace for thread http-127.0.0.1-8080-5
getEndpoint() ==> CompletionInitiator
Stack trace for thread default-workqueue-2 // n.b. worker 2 from initiator executor
setEndpoint(Interop11ATInitiatorService)
Stack trace for thread http-127.0.0.1-8080-6
getEndpoint() ==> Interop11ATInitiatorService
Stack trace for thread default-workqueue-2
. . .
setEndpoint(RegistrationService)
Stack trace for thread http-127.0.0.1-8080-9
getEndpoint() ==> RegistrationService
Stack trace for thread http-127.0.0.1-8080-9
setEndpoint(RegistrationService)
Stack trace for thread http-127.0.0.1-8080-9
getEndpoint() ==> RegistrationService
Stack trace for thread http-127.0.0.1-8080-9
setEndpoint(Interop11ATInitiatorService) // hmm, call is to initiator service
Stack trace for thread http-127.0.0.1-8080-9
getEndpoint() ==> Interop11ATParticipantService
Stack trace for thread default-workqueue-1 // oops wrong worker and endpoint!
setEndpoint(ActivationService)
Stack trace for thread http-127.0.0.1-8080-9
getEndpoint() ==> ActivationService
Stack trace for thread http-127.0.0.1-8080-9
setEndpoint(Interop11ATParticipantService) // hmm, call is participant service
Stack trace for thread http-127.0.0.1-8080-5
getEndpoint() ==> Interop11ATInitiatorService
Stack trace for thread default-workqueue-2 // wrong worker and endpoint again!
setEndpoint(ActivationService)
Stack trace for thread http-127.0.0.1-8080-5
getEndpoint() ==> ActivationService
Stack trace for thread http-127.0.0.1-8080-5
setEndpoint(Interop11ATParticipantService)
Stack trace for thread http-127.0.0.1-8080-8
getEndpoint() ==> Interop11ATParticipantService
Stack trace for thread default-workqueue-3
. . .
So, worker thread 1 was added under a call to the participant service and hence has this endpoint in its inherited therad local. However it appears to get reused to handle the initiator calls later. How so? I added some trace rules to see what exector was being used:
. .
setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATParticipantService)
Stack trace for thread http-127.0.0.1-8080-3
getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 0, active threads: 0, low water mark: 5, high water mark: 25]
Stack trace for thread http-127.0.0.1-8080-3
getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATParticipantService
Stack trace for thread default-workqueue-1
. . .
setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATInitiatorService)
Stack trace for thread http-127.0.0.1-8080-6
getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 1, active threads: 1, low water mark: 5, high water mark: 25]
Stack trace for thread http-127.0.0.1-8080-6
getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATInitiatorService
Stack trace for thread default-workqueue-2
setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATParticipantService)
Stack trace for thread http-127.0.0.1-8080-3
getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 2, active threads: 0, low water mark: 5, high water mark: 25]
Stack trace for thread http-127.0.0.1-8080-3
getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATParticipantService
Stack trace for thread default-workqueue-3
I added some more trace rules to see what is going on inside getExecutor:
RULE trace getExecutor
CLASS ContextUtils
METHOD getExecutor
AT RETURN
IF TRUE
DO traceln("foo", "getExecutor() ==> " + $!)
ENDRULE
RULE trace getExecutor internal
CLASS ContextUtils
METHOD getExecutor
AFTER CALL getNamedWorkQueue
IF TRUE
DO traceln("foo", "getExecutor called getNamedWorkQueue")
ENDRULE
RULE trace getExecutor internal 2
CLASS ContextUtils
METHOD getExecutor
AFTER CALL getAutomaticWorkQueue
IF TRUE
DO traceln("foo", "getExecutor called getAutomaticWorkQueue")
ENDRULE
RULE trace getExecutor internal 3
CLASS ContextUtils
METHOD getExecutor
AFTER CALL getInstance
IF TRUE
DO traceln("foo", "getExecutor called getInstance")
ENDRULE
This first rule prints the return value on the stack ($!) when getExecutor is about to return i.e. at the point where the original handler thread is queueing the runnable to execute the handed off message. The trace output reveals that the same executor is being used for both endpoints.
This appears to be because an executor is created per service. When the service has multiple endpoints then threads added to the pool can inherit an endpont at create but later be given jobs to run which are associated with one of the other endpoints.