Problem deploying a context (Servoy 8.2.3)

Questions and Answers on installation, deployment, management, locking, tranasactions of Servoy Application Server

Re: Problem deploying a context (Servoy 8.2.3)

Postby Andrei Costescu » Tue May 15, 2018 10:07 am

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.
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 939
Joined: Tue Jun 26, 2007 3:14 pm

Re: Problem deploying a context (Servoy 8.2.3)

Postby rieder » Tue May 15, 2018 4:38 pm

Hi Andrei

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.

Regards
Birgit Rieder
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
rieder
 
Posts: 98
Joined: Thu Jan 26, 2012 5:18 pm

Re: Problem deploying a context (Servoy 8.2.3)

Postby Andrei Costescu » Tue May 15, 2018 5:21 pm

Ok, here comes a large post.

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.
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 939
Joined: Tue Jun 26, 2007 3:14 pm

Re: Problem deploying a context (Servoy 8.2.3)

Postby rieder » Tue May 15, 2018 5:50 pm

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.

Kind regards
Birgit Rieder
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
rieder
 
Posts: 98
Joined: Thu Jan 26, 2012 5:18 pm

Previous

Return to Servoy Server

Who is online

Users browsing this forum: No registered users and 10 guests