Clients stay alive (Web-Client 5.1.4)

We recently updated a couple of our servers to 5.1.4.
Now we discovered there is a problem with disconnected clients, they stay alive in the server.

As seen in the screenshot below, the client has been idle since friday. (Actually the pc is shutdown now)
But the ‘Last alive check’ was today at 11.16. And it hasn’t cleaned-up the client?

In the server.xml of tomcat, we have set the timeout to 1 minute.

This is a big problem, cause at one of our webshops, this morning we had over 300 clients. (Only about 15 were active)
This has a huge impact on the performance. After a restart of the server, it works for a short time, but after abouth a 10-20 minutes it will start happening again, and the clients will stay alive.

Our server version:

As attachment I added the stacktrace.

server_stacktrace.txt (29.5 KB)

first 256MB for a server as max memory is a bit low, please up that to 512 or even 786.

I do see 2 clients hanging in the stacktrace you send over, i will investigate that a bit further.

The current RC of 5.2 already has a fix for that hanging client.

Ok,

Is there a indication when this RC will be released officialy?

this month is what we try to target.

Is there a way with the servoy updater, to go back to 5.1.3?

Cause to wait till the end of the month, isn’t really an option for us.

Johan,

This has actually been a huge problem for us as well on 5.1.4. We have been chewing thru licenses like crazy and eventually having to reboot the server to get our licenses released from clients whom have long-since “expired”.

I personally don’t think it is reasonable at all to tell folks to upgrade to 5.2 to cure this ailment and I think that Servoy needs to back port some of the major fixes from 5.2 into a 5.1.x maintenance release. I personally don’t have the time to deal with new [untested] features in 5.2 (like an entirely new security/authentication schema), I need 5.1.x to work - it’s only a month old! Can’t Servoy back port some of the fixes? I don’t get why [as usual] the focus is on new features before active; new and long-standing bugs are fixed in relatively fresh releases!

I’m watching the commit logs on 5.2 via the forge site and I see how much is changing. I’m quite certain 5.2. will introduce new bugs as a result of new features and “fixes” and my team doesn’t have time to bug test new features. We need a stable 5.1.x build? Can’t Servoy support 5.1.x for more than a month!?

Becoming very frustrated with the release schedule.

5.2 is a special release, its the open source release so thats where we now focus our attention mostly on.
5.1.x could have a maintenance release, its not decided yet.

Feature wise the 5.2 doesnt have that many new features, only changes that where needed for the open source (re)structuring. But most part it is just 5.1 but then open sourced. (and fixes that could come into a 5.1.x release)
So the focus is not on new features (except some we do in trunk of course for the real next version of servoy) but it is on making 5.2 as stable as possible for a release this month.

Paul told me the same thing on another thread, but the issue remains that I/others will have to upgrade to 5.2 (which does contain significant new features) in order to get these fixes. That honestly doesn’t seem reasonable for a one-month old release.

You told us that it is already fixed in the 5.2 release.

Does it cost a lot of effort to build only that fix into a 5.1.5 release?
I think you would please your customers with that!

as i said, we could do that, but it will not come before a 5.2 release that we try to target this month.

Ok, then I return to my previous question:

Is there a way to go back to 5.1.3, cause with that version we didn’t had the problem.
I searched for an argument or such to supply with the servoy_updater, but I couldn’t find any.

no the servoy updater can’t revert to a previous edition.
You have to install that one, please contact support if you need a install file for 5.1.3

Hi Johan,

Today is the fourth day in row that we have to restart the Servoy Server and kick out more than 50(!) users because the java.exe process lost his way with hundreds (>300) of clients which actually don’t exists. My customer is getting really angry because these users are the customers of his customer and this is not very nice marketing.

So I totally agree with jbader: we really need a 5.1.5 fix with this issue solved, please help us out.

Thank you.

I agree that clients should be disconnected after a while, but what I dont understand that it kills the java process! How many memory did you give the java process? (on windows you can find it in the wrapper.conf)

It has 1024mb, what is the max? It seems that at a certain point the java process starts to consume 100% CPU continuously, this probably is at the moment he reaches this 1Gb ceiling…

The OS is a Windows Server and we have 4Gb available but I remember that increasing the amount didn’t seem to reflect in the amount of memory shown at the servoy admin page, are there several setting for this?

In the mean while we received an intermediate 5.1.4i2 so our clients problem is solved for now.

the max memory you can assign is depending on the type of jvm you have installed (and if the os is 64 bit)

if java is a 32 bit install then the complete process can take up to 2GB, so the max heap will be i guess around 1.8GB or even less.

a 64 bit java this limit isnt there. I think there the limit is way beyond what we can put into a server at this moment…

Is

[fix] 295716 Sessions remain open on server

as mentioned in the releasenotes for 5.2 Beta 3 the fix for this problem?

I also had the problem that Janssenjos noticed when writing this case.

I made a request that could help him also.
I added a request that you can assign a maximum nr of licenses to a solution.
That can also help to minimize problems in a case like this in a SAAS setup.

By assigning a maximum nr of licenses to a solution, you can avoid that some webshop takes all the available licenses and there are no other licenses left for other solutions (for other customers).

By limiting the nr of licenses per solution, you can also avoid angry customers.

I hope Servoy will implement this in the next 5.2 release.

limiting the clients (=license) per solution, or per tenant, is allready possible.

//run on startup for each client
application.addClientInfo(“someUniqueIdentifier”)

//then get the number of clients with that info
var vCount = application.getClientCountForInfo(“someUniqueIdentifier”)

based on that count, you can decide, if clients are able to login, or not. if not, than log them out…
this way, you have in control, how many clients can connect per solution, or based per tenant, in a solution…