ny exceptions (that would trigger retry
> >> when
> >> session transacted) would be part of the asynchronous thread, not the
> >> JMS
> >> handling thread, so the retry is never triggered.
> >>
> >> Is there a way to have a synchronous one-
y spawn a new thread
>> (handles the request asynchronously) if the endpoint is one way. Since
>> it
>> is processed asynchronously, any exceptions (that would trigger retry
>> when
>> session transacted) would be part of the asynchronous thread, not the
>> JMS
>&
rigger retry
>> when
>> session transacted) would be part of the asynchronous thread, not the
>> JMS
>> handling thread, so the retry is never triggered.
>>
>> Is there a way to have a synchronous one-way (realizing that it is a bit
>> of
>>
ly) if the endpoint is one way. Since it is
>> processed asynchronously, any exceptions (that would trigger retry
>> when
>> session transacted) would be part of the asynchronous thread, not
>> the JMS
>> handling thread, so the retry is never triggered.
>&g
asynchronous thread, not the JMS
> handling thread, so the retry is never triggered.
>
> Is there a way to have a synchronous one-way (realizing that it is a bit of
> a contradiction) or is there a better approach with the CXF framework?
> Ultimately, I'm just trying to leverage
rigger retry
when
session transacted) would be part of the asynchronous thread, not
the JMS
handling thread, so the retry is never triggered.
Is there a way to have a synchronous one-way (realizing that it is a
bit of
a contradiction) or is there a better approach with the CXF framewo
dling thread, so the retry is never triggered.
Is there a way to have a synchronous one-way (realizing that it is a bit of
a contradiction) or is there a better approach with the CXF framework?
Ultimately, I'm just trying to leverage the JMS retry functionality for a
asynchronous web service oper
