RE: [rap-dev] Request timeout problems

["mail.apptech.nichost.ru" <ipavl@xxxxxxxxxxxxxx>]

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