Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » RAP and (cluster-)failover
RAP and (cluster-)failover [message #113556] Wed, 26 November 2008 10:48 Go to next message
Klaus Schroiff is currently offline Klaus SchroiffFriend
Messages: 6
Registered: July 2009
Junior Member
Hi folks,

I just did some load testing against a RAP prototype of our application.
Speed-wise things look fine indeed (for RAP at least :-) but there's an
issue which creates headaches here:

RAP seems to spawn one UIThread per user session and these threads do not
get terminated till their session timeout is reached. This seems to be a
rather hostile approach if you've a web-application with a rather long
session timeout (in our case it's at least 1h - preferably longer). During
the testing our application runs into out-of-native-threads after a while.
Ok, this may be acceptable when using load-balancing - possibly a 64bit
OS may also help here.
Anyway, regarding the UIThread characteristic it seems a little unlikely
that a RAP application is able to handle a failover in a cluster
environment (out-of-the-box). You may be able to replicate the http
sessions but the UIThread is out-of-scope here. Is that correct ?

thanks

Klaus
Re: RAP and (cluster-)failover [message #113582 is a reply to message #113556] Wed, 26 November 2008 12:28 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
>> RAP seems to spawn one UIThread per user session and these threads do
not
>> get terminated till their session timeout is reached. This seems to be
a
>> rather hostile approach if you've a web-application with a rather long
>> session timeout (in our case it's at least 1h - preferably longer).

We have the same problem.
We plan to adress this by having small a session-timeout (say 10min) and
embedding a 'ping' javascript which calls the server every 5min if the
user did no action.
For our intranet applications this will be sufficient.
If we are successfull I'm sure we'll post our solution here.
Re: RAP and (cluster-)failover [message #113595 is a reply to message #113582] Wed, 26 November 2008 13:19 Go to previous messageGo to next message
Klaus Schroiff is currently offline Klaus SchroiffFriend
Messages: 6
Registered: July 2009
Junior Member
> We plan to adress this by having small a session-timeout (say 10min) and
> embedding a 'ping' javascript which calls the server every 5min if the
> user did no action.
> For our intranet applications this will be sufficient.
> If we are successfull I'm sure we'll post our solution here.

But what do you gain by this ? You do not overcome the principal behavior
(one system thread per user session). By using your ping mechanism you
extend the lifetime of the session till the browser window is closed. So
out there you would risk keeping the UIThread alive for potentially much
longer than a reasonable session timeout because e.g. a business user may
not close a browser at all during working hours. Naturally you would mimic
a standalone application this way (which is good) but to me it seems as if
this blocks valuable server resources longer than necessary which is
naturally a problem assuming a couple of hundred or even thousands of
sessions (over the period of a day). You may argue that a shorter session
timeout may also produce less system threads if a users just works as long
as necessary (a short time) but is that a viable assumption in terms of
average amount of open UIThreads ?
Re: RAP and (cluster-)failover [message #113725 is a reply to message #113595] Thu, 27 November 2008 08:31 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
Actually my answer can't help you with fail-over or UI-Thread count, I'm
afraid ... I just reacted on the 'long sessions are problematic' part of
your post.
By having long session-timeouts most of the time we run into
memory-related problems.

Nevertheless we want to have long session timeouts, to mimic as you say a
standalone application where the user can go to lunch and then work on.
Unfortunataly most of the times users leave the application by closing the
browser instead of using a logout-button.

Our idea is just a try to have long running sessions with fast automatic
disposal if the users leaves. This is currently the best we could think
of, just to save a bit of server-resources (as I said - this might be more
memory-related).
We didn't collect any data yet how much server-resources could be released
by that on average, so I can't say if this pays off at all.


I also already thought, if RAP could employ some sort of UIThread-Sharing.
I think they can't do that by default - because noone knows for instance
if the application uses any ThreadLocals and alike.
Currently RWT itself uses ThreadLocals (see ContextProvider for instance).
Re: RAP and (cluster-)failover [message #113787 is a reply to message #113556] Thu, 27 November 2008 10:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rherrmann.innoopract.com

Klaus,

please see my comments below.

Cheers,
Rüdiger

Klaus Schroiff wrote:
> Hi folks,
>
> I just did some load testing against a RAP prototype of our application.
> Speed-wise things look fine indeed (for RAP at least :-) but there's an
> issue which creates headaches here:
>
> RAP seems to spawn one UIThread per user session and these threads do
> not get terminated till their session timeout is reached. This seems to
> be a rather hostile approach if you've a web-application with a rather
> long session timeout (in our case it's at least 1h - preferably longer).
> During the testing our application runs into out-of-native-threads after
> a while. Ok, this may be acceptable when using load-balancing - possibly
> a 64bit OS may also help here.
The UIThread was introduced to come closer to SWT and thus ease
single-sourcing. Specifically, Display#readAndDispatch()/#sleep()
rely on a UIThread.

We did load tests and have some RAP based applications running but
never hit this exception. Could you tell in what environment you
experienced this?

> Anyway, regarding the UIThread characteristic it seems a little unlikely
> that a RAP application is able to handle a failover in a cluster
> environment (out-of-the-box). You may be able to replicate the http
> sessions but the UIThread is out-of-scope here. Is that correct ?
You are right. Replicating the session seems possible, whereas
somehow "transferring" the current execution stack certainly not.

>
> thanks
>
> Klaus
>
Re: RAP and (cluster-)failover [message #113808 is a reply to message #113787] Thu, 27 November 2008 12:49 Go to previous messageGo to next message
Klaus Schroiff is currently offline Klaus SchroiffFriend
Messages: 6
Registered: July 2009
Junior Member
> We did load tests and have some RAP based applications running but
> never hit this exception. Could you tell in what environment you
> experienced this?

Hi Ruediger,

Environment:
Windows 2003 Server with 3GB
Tomcat 6.0.18
RAP 1.2M2
JVM 1.5.0_16
a fairly heavy-weight RCP app as a base

We were able to create about 500 sessions (equivalent to 500 UIThreads +
500 app threads (bug in the prototype)). Beyond 500 sessions we ran into
this problem. Naturally I tried to tweak the memory settings but didn't
really succeed.

See also this article regarding the system max. threads:
http://www.egilh.com/blog/archive/2006/06/09/2811.aspx
So no surprises here actually.

I'm sure you considered the problem but is is really a best practice to
spawn "persistent" threads in a servlet environment ?

cheers

Klaus
Re: RAP and (cluster-)failover [message #114025 is a reply to message #113582] Fri, 28 November 2008 14:56 Go to previous messageGo to next message
Michael Haendel is currently offline Michael HaendelFriend
Messages: 5
Registered: July 2009
Junior Member
Hi,

I had a very similar problem with the session timeout and and like to
share my solution.

To implement the 'ping' I wrote a custom widget based on a label. This
label is always empty but has to be somewhere on the UI. On the
client-side implementation it has a timer and every time the timer fires
it sends a request to server. When the browser is closed the timer stops
firing and the session timeout (5 Minutes) finishes the session quickly.

I will paste the sources here. The listener is not really necessary, but I
need it to refresh my database connection. Don't forget to register the
TLabelResource as extension.

Regards,
Michael.

package tlabel;
public class TLabel extends Label{
TLabelListener listener;

public TLabel(Composite parent, int style, TLabelListener listener) {
super(parent, style);
this.listener = listener;
}

public void fireStillAlive() {
listener.labelStillAlive();

}
}

public interface TLabelListener {
public void labelStillAlive();
}

public class TLabelResource implements IResource {
public String getCharset() {
return "ISO-8859-1";
}
public ClassLoader getLoader() {
return this.getClass().getClassLoader();
}
public String getLocation() {
return "webqueryui/custom/tlabel/TLabel.js";
}
public RegisterOptions getOptions() {
return RegisterOptions.VERSION_AND_COMPRESS;
}
public boolean isExternal() {
return false;
}
public boolean isJSLibrary() {
return true;
}
}

qx.Class.define( "webqueryui.custom.tlabel.TLabel", {
extend: qx.ui.basic.Label,

construct: function( id ) {
this.base(arguments);
this.setHtmlAttribute ("id", id);
this._id = id;
var timer = new qx.client.Timer(2000);
timer.addEventListener("interval", function(e) {
var wm = org.eclipse.swt.WidgetManager.getInstance();
var tLabelId = wm.findIdByWidget(this);
var req = org.eclipse.swt.Request.getInstance();
req.addParameter(tLabelId + ".stillAlive", "true");
req.send();
}, this);
timer.start();
}
} );


package internal.tlabel.tlabelkit;

public class TLabelLCA extends AbstractWidgetLCA {
public void preserveValues(Widget widget) {
ControlLCAUtil.preserveValues((Control)widget);
}

public void renderChanges( Widget widget ) throws IOException {
TLabel tlabel = ( TLabel ) widget;
ControlLCAUtil.writeChanges(tlabel);
}

public void renderDispose(Widget widget) throws IOException {
JSWriter writer = JSWriter.getWriterFor(widget);
writer.dispose();
}

public void renderInitialization(Widget widget) throws IOException {
JSWriter writer = JSWriter.getWriterFor(widget);
String id = WidgetUtil.getId(widget);
writer.newWidget("webqueryui.custom.tlabel.TLabel", new Object[] { id });
ControlLCAUtil.writeStyleFlags((TLabel)widget);
}

private static final String PARAM_STILL_ALIVE = "stillAlive";

public void readData(Widget widget) {
TLabel tlabel = (TLabel)widget;
String stillAlive = WidgetLCAUtil.readPropertyValue(tlabel,
PARAM_STILL_ALIVE);
if (stillAlive != null && stillAlive.equals("true")){
tlabel.fireStillAlive();
}
}
}
Re: RAP and (cluster-)failover [message #114059 is a reply to message #114025] Sun, 30 November 2008 21:24 Go to previous messageGo to next message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
Michael,

thank for sharing your solution !
Are you custom to phase-listeners ? These could maybe be used to 'inject'
your javascript more easily.
Lock for a thread called 'Logout Action' and the answer from Stefan Roeck.
There he registeres a phaselistener (to do a redirect, but that's not
important hre) which is triggered exactly once and used to send a
javascript to the client.

Anyway ... I like your solution and as we have a statusbar it shouldn't be
to difficult to use your label as it is.

@RAP-team ... does it make sense to post this snippet in the wiki ?
Re: RAP and (cluster-)failover [message #114083 is a reply to message #113808] Sun, 30 November 2008 19:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rherrmann.innoopract.com

Hi Klaus,

thanks for your information. Please see my comments below.

HTH
Rüdiger

Klaus Schroiff wrote:
>> We did load tests and have some RAP based applications running but
>> never hit this exception. Could you tell in what environment you
>> experienced this?
>
> Hi Ruediger,
>
> Environment:
> Windows 2003 Server with 3GB
> Tomcat 6.0.18
> RAP 1.2M2
> JVM 1.5.0_16
> a fairly heavy-weight RCP app as a base
>
> We were able to create about 500 sessions (equivalent to 500 UIThreads +
> 500 app threads (bug in the prototype)). Beyond 500 sessions we ran into
> this problem. Naturally I tried to tweak the memory settings but didn't
> really succeed.
Jobs worker threads are pooled, servlet engine request threads are
pooled also. Wouldn't that mean that, without the bug in the
prototype, there are approx. 1,000 threads minus 100 (?) pooled ones
left over over for UIThreads?

>
> See also this article regarding the system max. threads:
> http://www.egilh.com/blog/archive/2006/06/09/2811.aspx
> So no surprises here actually.
From reading the blog entry, there is space for individual
optimization left. Like using a 1.4 JRE, -X options.

>
> I'm sure you considered the problem but is is really a best practice to
> spawn "persistent" threads in a servlet environment ?
Our primary goal was to achieve single-sourcing with RCP code. This
lead to the choice to implement Display#readAndDispatch()/sleep()
which requires a "persistent" UIThread.
In addition, it turned out to be the most straight forward (== least
error prone) solution. For more details, please search the newsgroup
for "readAndDispatch".

>
> cheers
>
> Klaus
>
>
Re: RAP and (cluster-)failover [message #114102 is a reply to message #114083] Mon, 01 December 2008 08:42 Go to previous messageGo to next message
Stefan   is currently offline Stefan Friend
Messages: 316
Registered: July 2009
Senior Member
Hi,

the number of maximum thread also depends on the HeapSpace (partly
indirect proportional). According to [1] more than thousand threads are
possible in Java5.

However, I think it should be clearly said, that RAP applications can
handle several hundred or thousands concurrent users (in a load balancer
scenario) pretty well, if designed correctly. However, if someone
expects 100.000 users or more, another technology might be the better
choice.

Just my opinion...
Regards,
Stefan.

[1] http://forums.sun.com/thread.jspa?threadID=645335&tstart =20


Rüdiger Herrmann schrieb:
> Hi Klaus,
>
> thanks for your information. Please see my comments below.
>
> HTH
> Rüdiger
>
> Klaus Schroiff wrote:
>>> We did load tests and have some RAP based applications running but
>>> never hit this exception. Could you tell in what environment you
>>> experienced this?
>>
>> Hi Ruediger,
>>
>> Environment:
>> Windows 2003 Server with 3GB
>> Tomcat 6.0.18
>> RAP 1.2M2
>> JVM 1.5.0_16
>> a fairly heavy-weight RCP app as a base
>>
>> We were able to create about 500 sessions (equivalent to 500 UIThreads
>> + 500 app threads (bug in the prototype)). Beyond 500 sessions we ran
>> into this problem. Naturally I tried to tweak the memory settings but
>> didn't really succeed.
> Jobs worker threads are pooled, servlet engine request threads are
> pooled also. Wouldn't that mean that, without the bug in the
> prototype, there are approx. 1,000 threads minus 100 (?) pooled ones
> left over over for UIThreads?
>
>>
>> See also this article regarding the system max. threads:
>> http://www.egilh.com/blog/archive/2006/06/09/2811.aspx
>> So no surprises here actually.
> From reading the blog entry, there is space for individual optimization
> left. Like using a 1.4 JRE, -X options.
>
>>
>> I'm sure you considered the problem but is is really a best practice
>> to spawn "persistent" threads in a servlet environment ?
> Our primary goal was to achieve single-sourcing with RCP code. This
> lead to the choice to implement Display#readAndDispatch()/sleep()
> which requires a "persistent" UIThread.
> In addition, it turned out to be the most straight forward (== least
> error prone) solution. For more details, please search the newsgroup
> for "readAndDispatch".
>
>>
>> cheers
>>
>> Klaus
>>
>>
>
>
Re: RAP and (cluster-)failover [message #114108 is a reply to message #114083] Mon, 01 December 2008 09:09 Go to previous messageGo to next message
Klaus Schroiff is currently offline Klaus SchroiffFriend
Messages: 6
Registered: July 2009
Junior Member
> Jobs worker threads are pooled, servlet engine request threads are
> pooled also. Wouldn't that mean that, without the bug in the
> prototype, there are approx. 1,000 threads minus 100 (?) pooled ones
> left over over for UIThreads?

That is correct. We are expecting about 10.000 Users which is not that
much on paper but a fair share (low to mid double digit) of these users
will use the application on a daily basis.
Now assuming that few users will actually log out manually (few do after
all) this will be a borderline thing when assuming a max. of 1.000
UIThreads on a single machine.
Well, the local bosses seem to have less problems with this thought than I
do so the problem solution will be to throw in more hardware. :-)

cheerio

Klaus
Re: RAP and (cluster-)failover [message #114195 is a reply to message #114059] Mon, 01 December 2008 17:08 Go to previous message
Michael Haendel is currently offline Michael HaendelFriend
Messages: 5
Registered: July 2009
Junior Member
Hi Stefan,

I just tested the HtmlResponseWriter and it seems not sufficient for that
purpose. I can't find a way to hook the JavaScript timer into any of the
LCA's.

It looks like that sending an empty request to the server is not enough to
keep the session alive. You have to do something in the
TLabelListener-callback. If I do a "System.out" it seem to be enough, but
if the callback is empty the session is still terminated. I really don't
understand it: The server gets a request, but doesn't reset the session
timer. May somebody from the RAP team can help on this issue.

Regards,
Michael.
Previous Topic:How to Use a JPanel in a Single-Sourced RAP/RCP app?
Next Topic:RAP and Draw2D/GEF
Goto Forum:
  


Current Time: Sat Jan 28 06:13:46 GMT 2023

Powered by FUDForum. Page generated in 0.13057 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top