[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [rap-dev] Request timeout problems
|
Hello
> However I am hesitant integrating this change in RAP since I am not aware
that this a broader use case.
I agree that you should not include such changes in target 1.2. Maybe later.
And it is not a big problem - not to have this change in main CVS. I can do
a patch or rebuild platform if necessary.
> BTW can't you just re-configure the application server?
No, it is impossible. It is too big restriction. And it will be impossible
to everyone who have not dedicated server.
I made a bit more. I implemented a notification system based on UICallBack
mechanism. So I can notify users (their browsers) about some changes.
This change allows users to interract with each other and allows to use
redirection with a better way (using of Browser control to redirect user is
a very strange solution). For example, I can redirect user to another url
with UICallBack. I used an event-based strategy and this fix causes changes
only in API of UICallBack (method to add a special listener added and a
method to send a notification event).
I will prepare a patch and some tests for my fix. I hope it will be usefull
for somebody.
Cheers,
Igor
-----Original Message-----
From: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rudiger Herrmann
Sent: Wednesday, June 17, 2009 9:04 PM
To: RAP project development-related communication
Subject: Re: [rap-dev] Request timeout problems
Hi again Igor,
I don't see any obvious problems with your change.
What needs to be ensured, is that the return value from
UICallBackServiceHandler#jsUICallBack() contains
"org.eclipse.swt.Request.getInstance().enableUICallBack();"
(the then-branch of the if-statement gets executed) Otherwise the callback
mechanism would be interrupted.
Note that the change in a sensitive area that isn't completely covered by
unit tests. We can't (yet) test the interaction between client and server.
Therefore, test thoroughly before going productive.
However I am hesitant integrating this change in RAP since I am not aware
that this a broader use case.
BTW can't you just re-configure the application server?
Cheers,
RĂ¼diger
mail.apptech.nichost.ru wrote:
> Hi
>
> I have a problem with UICallBackServiceHandler.
>
> As you know, UICallBackServiceHandler#service method calls
> UICallBackManager.getInstance().blockCallBackRequest() wich blocks
> itself until the server requires UI updates. But some application
> servers (like
> WebSphere) have a group of settings for managing request timeouts
> (Object Request Broker in WebSphere, for example). So the application
> server can terminate such request by timeout.
>
> I used a simple fix: I changed in
> UICallBackManager.blockCallBackRequest()
> "runnablesLock.wait();" to
> "runnablesLock.wait(MAX_REQUEST_TIME);". I also added a constant
> MAX_REQUEST_TIME = 10000
>
> And it is working fine. But I have a question: is there any code that
> depends on UICallBackManager state? I am not sure that my fix is
> correct. If it is incorrect, could you please describe problems that I
> can get with my fix? I will try to solve them.
>
> If this fix is correct and somebody interesting in such functionality,
> I think it is possible to made additional system setting or something
> like this to allow programmers writing applications wich should not
> lose connection to server where opened in browser.
>
> Thank you,
> Igor
>
>
> _______________________________________________
> rap-dev mailing list
> rap-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev