Servoy Forum

Talking about Servoy 8.2.3, when we are deploying a context (WAR file) for the first time, it is working as expected, i. e. the context starts up (in Tomcat server). As soon as we enter on the Servoy admin page the license - stop and start the context again, it won't start anymore. The license is accepted as ok and works already for a long time in production without any problems using Servoy version 8.1.4.
We can enter or alter other values in the Servoy admin page like date or number formats and these changes do not have nay negative impact. Java version did not change, it's 1.8.0_151.

Is there a new license needed when changing from Servoy 8.1.4 to 8.2.3? Although I can't image that within the same major Servoy version, the problem always occurs when entering a license (tried with more than one).

Anyone made the same experience?

Thanks and regards,

Hi

Any help available? We don't know, how to continue. We planned to migrate from 8.1.4 to 8.2.3. But since that problem occurs, which Robert explained, we are stuck.

The application server (inside Tomcat) runs fine, as long as we do not enter the license. (Of course with a warning whenever we start the application). But as soon as we enter the license

- via admin page or
- manually in the properties file or
- when creating the WAR file

the context (application server) does not start any more. Even Tomcat will not start again. Logfiles are no help.

Any ideas?

Thanks and regards

Additional information:

The problem only occurs, if we import a solution into a context.
So, deploying our NG client works, unless we import a headless client.
But deploying an empty (application server only) context fails, as soon as we import our Smart Client solution.

Ideas will be VERY appreciated.

Regards

we really need more info and logs

tomcat logs (tomcat/log) or servoy logs (tomcat user/.servoy/context/xxxx). Are you sure there is no info at all in that?
The whole tomcat doesn't start up? or only that context? Because tomcat really should not be affected if for some reason a context doesn't want to get up because of an error.

you should be able to import stuff just fine in a WAR, the war is pretty much exactly the same as a applicaiton_server.
The only thing is that a WAR only has the ngclient resources to be able to run ngclient solutions.

Hi Johan

Thank you for the reply! The problem took as days, already.

• I'll create new log files and attach them.
• The «broken» context can be stopped, but will not start. The process in the browser does not end.
• Same for Tomcat. As soon as one context is broken, Tomcat does not start again. It somehow «hangs» in the launching process. I need to kill the process and delete the WAR file and the unpacked folder in the web apps folder. Or delete the license in the Servoy properties file.
• Your hint with the ngclient resources raises a question: Which services need or may not be exported? Or may a bean or plugin or component lead to a problem? Deployment was no problem with 8.1.4. What is the difference?
• What is the problem with the license? As soon as we delete it in the properties file, the context and Tomcat work as expected. Can you confirm, we do not need a new license with 8.2.3?

Thanks and kind regards

license should work fine, also even if those where invalid then it still shouldn't be a problem.
But is it the license or the import of a solution?
What does happen if you attach a license that it checks that license to our server, so that should be reachable.

also trying to run ngclient stuff when something is not exported will just result in clients not fully working, the context should startup.
Maybe with a tool like jstack.exe (which is in the jdk install) you should be able to dump the stack when tomcat is hanging.

Hi Johan

- Please see attached the log files. From Servoy (servoy_log.txt) and from Tomcat (5 files).
- It's reproducible. We did this many times: Deploy the WAR, import a solution, enter the license --> Bang! Remove the license --> It works!
- I'll read the manual, how to use jstack. I'll be back with the stack file.

Thanks again and regards

Hi Johan

I attach two files. One stack with running contexts (ok_dump.txt).
One after entering the license and during restart of the context (not_dump.txt).

I hope, you find the problem. At least I see deadlocks listed.

Thank you and kind regards

thats a deadlock when loading in the solution (or better said the columinfo for the tables)

We need to have a look at that

Yes, please do that. Would be great, if you find the problem!!!

What the hell is the relation to the license in the properties file? I know, it sounds weird. But we can reproduce it.

there is no license issue here. Its all about loading in the solution(s) and loading in the column information at the same time in 2 threads
And then the solution hits a a stable that has no column info (which is a bit weird) so it auto creates it but it is also busy creating it already in the other thread.

Not sure how it is possible that there is no column info for certain tables at the server. Especially tables that are used by the solution.

I created a case for this in JIRA: SVY-12426.

Thank you. So we wait for news.

It was a regression from a case included in 8.2.3, but it should be fixed now (in next public release - 8.3.1)

Can you please check if the problem is resolved in your setup as well? I want to make sure there aren't still other similar problems. Steps to check that:

• close/stop 8.2.3 app. server & developer; backup your 8.2.3 install
• download latest 8.2.x servoy_update.zip. Note: this update zip might also contain other untested/not-yet-released code changes.
• extract it on top of your 8.2.3 install and replace existing files
• in servoy.ini (for developer), add a "-clean" line at the beginning of the file
• check to see if problem is solved

If you are using Mac, the contents of the update zip have to be copied a bit differently as there the folder structure of the install is different.

Hi Andrei

I can confirm, that this update fixes the above problem.

Could you please supply me with some additional information: What was the problem, does it occur everywhere? Have we been the first company to use 8.2.3 and WAR deployment? Shouldn't you report this problem in the forum, so no other developer spends hours and days, trying to update? We must wait for 8.3.1 now, right?

I have no clue, how this version, which creates an application server than cannot be launched, could ever be released. Anyway, I'm glad the problem is identified. Thanks for your answers and your help.

Kind regards