Well, the final callflows will be something like that :

GET RES_1 ---> JAX-RS
______________ *wait*
______________ JAX-RS <--- GET RES_2
______________ JAX-RS ---> 200 OK + DATA
_______ * do other things *
__ 200 OK <--- JAX_RS

I need the asynchronous thing for scaling (no point in doing the logic in a 
thread). And I'd like to have the timeout working in order to: have a watchdog, 
have the feeling on relying on something that is working.

That being said I took a closer look to the source code and found many mistakes 
(there are probably not a lot of people using that feature). I attached the two 
classes I had to fix (for people that might have the same issue and find this 
thread). I'll fill a bug report later with patch, once I test this code more.

One of the most "obvious" (well, not when reading) mistake was:
//long timeout, time;
//TimeUnit unit;

timeout = unit.convert(time, TimeUnit.MILLISECONDS);

Instead of:

timeout = TimeUnit.MILLISECONDS.convert(time, unit);

But then again, that was not the only one: the "logic" for setting the 
setTimeout seemed invalid, and the handleTimeout method could never be called.

With the "fixed" (not sure it's fixed the best way) classes in my jar 
(overriding CXF's), I think I have a clean behavior on tomcat 7.0.32 and JBoss 
AS7.

Note that the timeout management by the AS does not seem very precise.
Tomcat's precision is around 1 second.
JBoss's works with steps of 10 seconds.

Well, now that asynchronous server-side jax-rs seems OK, what about 
asynchronous server-side jax-ws ? :-)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.

Reply via email to