|
|
|
|
| Re: RAP and (cluster-)failover [message #113787 is a reply to message #113556] |
Thu, 27 November 2008 10:44   |
Eclipse User |
|
|
|
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 #114025 is a reply to message #113582] |
Fri, 28 November 2008 14:56 |
 Michael Haendel
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 #114083 is a reply to message #113808] |
Sun, 30 November 2008 19:28 |
| Eclipse User |
|
|
|
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 |
Stefan 
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
>>
>>
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04263 seconds
] 
Search
Help
Register
Login
Home
