The concurrent processing of a service provider is not stable. It is due to the actual POJO design that is not stateless:
only one instance of POJO is loaded on SU deployment,
on each message processing, the JBI listener is set on the POJO.
If several processing are concurrent, the JBI listener is changed, and strange problems can occur.
The JBI listener must be set as parameter on POJO methods called to process messages.
SU developped with previous versions of the SE POJO will not be compatible with the new one.
The concurrent processing of a service provider is not stable. It is due to the actual POJO design that is not stateless:
only one instance of POJO is loaded on SU deployment,
on each message processing, the JBI listener is set on the POJO.
If several processing are concurrent, the JBI listener is changed, and strange problems can occur.
The JBI listener must be set as parameter on POJO methods called to process messages.
SU developped with previous versions of the SE POJO will not be compatible with the new one.
Christophe DENEUX added a comment - Mon, 23 Apr 2018 - 12:30:53 +0200 Reopen because it is not needed to use a ThreadLocal to store the current POJO to use
Fixed in trunk