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).
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.
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.
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.
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?
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.
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.
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.
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.
Yes you either have to wait for 8.3.1 or go back to the previous version that you were using (unless we can identify why it happens specifically for you and you want to work around that - see below).
The problem was 2 threads blocking each other: one thread is the thread that loads in the background used servers/tables structure so that when they are accessed for the first time by solutions they load faster, and the other thread was the app. server startup that prepares solutions for usage. This problem appears if - for some reason - there is no column information in the repository for columns in multiple tables that are used by solutions. So you have to have multiple tables that have new columns that Servoy was previously unaware of. That doesn’t usually happen as far as I know after server restart.
I managed to reproduce it by manually adding new columns to some of the tables while app. server was offline & putting some code breakpoints in place to simulate the deadlock.
Do you know how that happens in your case? So some of the tables used in your solutions/modules having columns that the Servoy repo. was unaware of at server startup.
Thank you for the reply. We did go back to 8.1.4 and deleted all «experiments» with 8.2.3. We’ll wait for 8.3.x
And thanks for your explanation of the reason for the deadlock. Do I understand you right: The table structure which came with the database servers of the Servoy application server (context 7r) was different to an applications (.servoy file) dbi files? And the difference made a «compare process» during startup last longer than before or than expected, so that it blocked the app server from launching? More or less? I have problems understanding «…no column information in the repository for columns in multiple tables that are used by solutions…»
Hm… And it has nothing to do with reading the license, validating it, unlocking something or anything similar?
Anyway, we went back to 8.1.4 without any problems. Everything works as before and as expected.
You are right in mentioning the .dbi files. That is where column information is kept in developer (as the ‘repository’ of a developer is made up of files in the workspace).
But in application server, the same information is stored not in .dbi files but somewhere in the repository DB server (that is the ‘repository’ when running from the app. server).
Column information keeps information - relevant to Servoy - about columns. For example: if a column is a servoy seq., defaults, auto-enter, column converter name and so on…
Let’s say you have two tables A and B.
After you did the .servoy import of your solution in the app. server through admin page, Servoy had column information about columns colOneA and colTwoA from table A and about columns colOneB and colTwoB from table B.(either because the .servoy file didn’t contain that information or because the columns were really not yet there in the DB)
Then you restart tomcat or redeploy.
When Servoy app. server starts it finds on two separate execution threads that I described earlier that:
table A actually has in the database also colThreeA but it does not find column information about that column in the Servoy repository (this is what one thread finds)
table B actually has in the database also colThreeB but it does not find column information about that column in the Servoy repository (this is what the other thread finds)
Both threads try to generate a default column information for their column (colThreeA and colThreeB), which is normal and it works like that since I can remember. Because of some implementation details on how code acquires locks on those threads and what locks they already have (these details have changed in 8.2.3), the two threads end up waiting indefinitely after each-other. So it doesn’t last longer, it lasts forever…
It doesn’t seem related to licenses at all. But as almost all bugs where threads block each-other are involved it is possible that having a license delayed a bit one of the two threads; so that it made it more likely to get into this situation. If the two threads would not execute those parts of code at the same time - so thread 1 finished it’s job before thread 2 found it’s ‘special’ column then the two threads would not have blocked each-other. Also if Servoy would not detect at all columns for which it has no column information, the deadlock would not occur.
Wow, quite a large post. We at 7r already read it, discussed it and thank you for the description of the process. It helps us to extend or confirm the pictures in our heads.