-
1. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
lvdberg Jun 9, 2009 6:07 PM (in response to jan1972)Jan,
I don't think it's a bug. Sleeping a thread in this was is a very
no-do
in web applications. I think its cashing on trying to accces the locked properties of the class.Leo
-
2. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
yahawari Jun 10, 2009 4:29 AM (in response to jan1972)i am working on an application that has a few functions which do take a long time to finish. if the user clicks on the button twice he will definitely get this . Seam guy know this, so they advice u to use @Asynchronous with poll functionality of richfaces. there are other ways to deal with this if richfaces is ur UI. have a look at seam's guide section 7.11
-
3. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
jan1972 Jun 10, 2009 8:56 AM (in response to jan1972)Leo:
I am not sure I understand what you mean... Actually I called it a crash, but it's an uncaught exception raised by Seam because the conversation Manager fails to acquire the ConversationEntry lock.
If ce.lock() returns false, there is an explicit:throw new ConcurrentRequestTimeoutException(
Concurrent call to conversation
);So, admittedly that Thread.sleep() is not a good idea, it might be something else taking some time: database hit, computations, even another process.
To tell you the truth, by fast clicking, I managed some times to reproduce it without the Thread.sleep(), but you gotta be patient/lucky, which is why I added the sleep.Yasser:
Thanks for the tip. @Asynchronous is something we already use in several places. The issue is that this time, we are developing an interface which needs to be accessed from a cell phone (and not only smart phones, also the pretty old/basic ones) and therefore, we cannot do JavaScript to poll for anything. -
4. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
marx3 Jun 10, 2009 9:26 AM (in response to jan1972)The only working method is to completely block UI after button/link click. I do that via onClick method showing modal div
please wait
on top of a page. When request is completed, page reloads (without div). -
5. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
lvdberg Jun 10, 2009 9:42 AM (in response to jan1972)Jan,
Fast clicking can be helped completely by adding a Queue to your pages. Adding ajax buttons which reference that queue can help you eliminate this behaviour.
It needs some tuning, but it works perfectly. It basically helps you wait for a response until the previous one has finished.
Be aware that web-technology is NOT perfect, but luckily JBoss also provide help for you client side. Loot at the Ajax4JSf documentation.
Success,
Leo
P.S. Be more positive, I think the Seam guys have done a great job, and don't blame them for the problems in HTTP!
-
6. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
jan1972 Jun 10, 2009 9:43 AM (in response to jan1972)This UI freezing is a good solution when you allow yourself usage of JavaScript. As explained earlier, we do not (in that very particular case).
What surprises me is that such a double-click issue apparently already existed in regular JSF pages in early versions of Seam... and now it seems that I just unveiled a similar issue in the pageflow. See: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3979681
Also, in Seam 2.0.2.SP1 which we used so far, this used to work, apparently because the conversation ID was not always properly propagated, which seems to have been fixed in 2.1.1.GA -
7. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
jan1972 Jun 10, 2009 9:58 AM (in response to jan1972)Sorry Leo, I had not yet seen your answer. As said in that case, I have no choice to use any JavaScript unfortunately (basic cell phone application).
Anyway, thanks for your answers.
From these, I conclude that this is neither a bug nor something I have a workaround for.
So all I can do is dropping Seam/jBPM and using a not concurrency-locked model (and manage the locks by hand in my own code). Is that correct?
Leo van den Berg wrote on Jun 10, 2009 09:42:
P.S. Be more positive, I think the Seam guys have done a great job, and don't blame them for the problems in HTTP!Did I give the impression to blame anybody? or even to be negative??? Reading again my posts, I have always been rather factual. If not, this is something for which I apologize.
-
8. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
lvdberg Jun 10, 2009 10:08 AM (in response to jan1972)Sorry for that, was not my intention,
but this discussion is more about the problems we all encounter in using WEB cleinst, the client want's it, but I am still puzzled how it is possible that we still need to create more-aand-more framework which abstract away all those problem instead of solving the problem at its source; the limitations of HTTP.
Your first email starts with :
I believe I have found a bug
and ends withMay I submit a bug?
while you described a web / HTTP-problem,Sorry for my my rudeness, I apologize for that,
Leo
-
9. Re: ConcurrentRequestTimeoutException when double-clicking in jBPM
jan1972 Jun 10, 2009 10:27 AM (in response to jan1972)No problem.
I am being factual and am still personally convinced that this is a bug in the conversation management in Seam. Or let's phrase it another way if you wish: Seam's promise to provide conversation management causes more problems than it solves in this very particular case.
This is why I was using this
bug
phrasing. Also bugs are in the very nature of software, so I don't see nailing one down as being negative, in the contrary.Cheers
Jan