Stress test crash

[ishopservice]

If I stress test my application it crashes and the application restarts. In JavaFX it runs just fine.

Allowing more memory does not make any difference. A tail -f on nohup.out shows the logging below.

What is this numbers 1064505139 in the logging? Is it possible to have a stack dump or something?

[info] c.jpro - application requested: 1064505139!solar [info] c.jpro - Creating Application: 1064505139!solar [info] c.jpro - remoteAddress 213.127.9.94 [info] c.jpro - host 82.94.102.99:8090 [info] c.jpro - uri /app/1064505139!solar [info] c.j.i.s.ViewInfo$ - [info] c.j.i.s.ViewInfo$ - Application closed:

j

[FlorianKirmaier]

The numer basically means "try to connect me to my old session or if it no longer exists, create a new instance of the application solar.

Is there an actual problem you found while testing your application?

[ishopservice]

HelloJPro.zip I created a minimal application, based on HelloJpro, to illustrate the crash problem. It shows the exact problem I expirience in my application.

If you start up, you can enter the number of panels. Enter some low numbers to watch the desired behaviour. Then you enter a large number, say >5000. The JavaFX version handles these 5000 panels with ease. The Jpro version crashes and shows the same behaviour as my application. I stripped as much code as possible. I hope this helps us to detect the problem.

[ishopservice]

open

[FlorianKirmaier]

@ishopservice Thank you for the test application. Is this only a synthetic test, or do you have similar requirements in your application?

Some notes about it:

• The page reloads because the javascript client tries to reconnect if it doesn't hear anything for 10s from the server. This time is configurable in the JProTag <jpro-app timeUntilReconnect="600000" ...>
• The usual way to solve this problem is to use controls which are dynamically loading the visible content, like ListView, TableView etc. This way the number of nodes gets greatly reduced. In the sample, the number of nodes would be always about 30, even when a million elements are in the ListView.
  • Even so, JPro takes longer to load these Nodes, afterwards the scrolling is much faster as the desktop-client.
• The latest version 2019.1.3 introduced a performance improvement to the browser-client, which slightly improves the situation.

There is some optimization potential for JPro loading a lot of nodes, but the normal solution would be to use ListView. It also would be nice, if it would just take longer when more nodes are loading, instead of just "refereshing" because the client isn't sure whats happening on the server.