So with a fresh install (or updated plugins/beans) you did notice it
Then after a restart it behaves well?
then it could be related to pack200, because after a restart no more packing is done because that was done before and is cached.
But then you should be able to reproduce it by deleting the work dir in the server dir… So that it will recreate the pack files.
ok
because of the post of Adrian i was again looking at the pack200 thing
Because i already had a feeling that it was that or a 3th party plugin
The thing is that code is in our code base for a long long time, so why suddenly people have problems…
But i figured it out it is because Webstart changed in the latest versions,
What webstart does now is sending multiply request at the same time to the server to get jar files (before it did 1 by 1)
And because /lib and /plugins are different web applications they are separated from each other so our synchronization that was already in place didnt synchronize over the different webapplications
So 2 or more pack request could happen at the same time
And because Pack sets the timezone to UTC and remembers the previous one does it stuff and then sets the remembered TimeZone back we have a problem if there are multiply request over different web app contexts…
request 1:
gets the current Timezone (CEST) to remember
sets UTC
goes packing
at the same time request 2:
gets the current timezone (is UTC because of request 1)
goes packing
then request 1 is done
sets it back to CEST (until now everything is ok)
but then request 2 is done
sets his remembered time zone back and that is UTC so now we lost CEST
I will fix this by making sure that even over different context it will only pack 1 at a time…
the current fix for you guys is
Update your server with new jars
start up the server
start 1 smart client to make sure all your jars are checked and packed.
restart server.
Johan,
I can remember indeed that the (first time) packing of files was MUCH faster with later java versions. before, packing was really slow.
Does that mean after the fix, that packing will be slower again??
jcompagner:
the current fix for you guys is
Update your server with new jars
start up the server
start 1 smart client to make sure all your jars are checked and packed.
restart server.
Maybe it’s me, but what I read is:
whenever we update the server with new jars, we have to:
when doing a single jar file. i do think that that will go ok
But updating 2 jar files could reproduce this problem
Because with 1 there is only 1 request from the client to that jar
But with 2 there is a possibility that those 2 happen at the same time.
Harjo: pure packing must be serialized, so yes if you have a multi core system (most servers are these days) then doing the pack for many at the same time will speed it up
So doing it now serialized again will mean only 1 core does the job.
But this is a 1 time hit for the first client you start.
Oke, maybe packing the jars, can be fired by the server itself than, instead of launching a (first) client by hand…
Harjo:
Oke, maybe packing the jars, can be fired by the server itself than, instead of launching a (first) client by hand…
Great idea Harjo, I’m with you!
and that fixes not much because what happens if you start a client when the server is still doing it stuff?
this could be an addon yes but that still would mean synchronizing at the same places.
Or we have to do it even earlier before we even startup tomcat, But that would mean that a quick startup of a server especially when you have updated quite some jars is not possible.
And you have to start up a client your self after a restart/update of jars anyway to check if it works!
(remember it is only when jars are updated!)
I noticed also the change of CEST to UTC, but …
I was on holiday for 1 week and during this week there was no import of (updated) solutions and also no restart of the application server and now after 1 week I see that the time is still on CEST.
Could it be that the problem only happens after a restart of the AS?
as explained above, it happens when you update jars on the server that then are downloaded to the client…
So if you restart your server when there are updated jars, then yes it could happen.
But if didnt have any updates when you restart nothing should happen.
jcompagner:
So if you restart your server when there are updated jars, then yes it could happen.
But if didnt have any updates when you restart nothing should happen.
I’m afraid that is not the case Johan.
Yesterday there was a solution update, but no restart of the server and this morning I saw that the time was changed from CEST to UTC.
There were no updated jars.
When I update jars (and that is only when I update Servoy version or an update of a third party plugin), then I always stop and start my AS
And before restarting the AS, I clean also the C:\Servoy_41\application_server\server\work\Catalina\localhost directory
I guess that there are no automatic jar updates from Servoy?
When I check the dates of all jar files, none of them have a recent date.
The only thing I noticed is that in my 4.1.6 AS there is no timezone.default setting in the property file.
Could that be a reason?
if you clean the work dir
then the next time a client ask for jars every jar is generated and thats the same thing as updating jars.
but if you do that then it only generates jars for a client that has not yet those jars
so it is perfectly possible that you dont notice it at all but suddenly 1 new client that downloads jars that others didnt do yet and there you have the utc time zone change
We have the same problem with the date on the server changing to UTC (from BST) but we can reproduce it without puting a new version on the server or updating any jars on the server.
If we delete the Java cache on the client and then start the smart client it re-downloads the application through the Java Web Start and the date on the server changes to UTC.
If we restart the server then back to BST. All OK until we delete the cache on the client and as soon as we restart the smart client and the web start downloads the application the date changes back to UTC on server.
Servoy version 5.1.4, server OS Windows Server 2008, Java on server and client 1.6 build 20.
Made a case for swithing to UTC after an update (298402). Servoy support says this will be solved in the next 5.x release(s). Hope the case Iain describes will also be adressed. It would be a big problem when server time switches to UTC every time a client clears his java cache… (I cannot reproduce this however)
I had the problem re-occur the other day on 5.13, when i simply had restarted the servoy service.
Although i didnt purposely clock it, i am 98% sure that when i restarted this from the train yesterday, as my office called to say all appointments were going out one hour earlier than booked, that the client page on the servoy admin panel had UTC by the clients.
After restart it says BST.
I had not updated my solution before restarting the servoy server service.
SO i think this reproduces the same error you are commenting on.
David
Running for a week now with a new version and all of a sudden the Application Server time switched back to UTC again! Don’t know whether one of the users cleared his java-cache.
This is becoming a serious problem. Will this issue be solved in Servoy 5.1.5 and when will this version be available? Maybe someone from Servoy can comment on this.
OK,
I have this issue reproducible and nailed.
If you upload a new version of your software, the dates on all the clients immediately change to UTC in the servoy admin panel.
If you then restart the servoy service they revert to BST.
This seems independent of any client macbines , it just happens the instance i upload a new release.
So the workaround for the moment is to always restart Servoy after updating your solution. I assume a case has been made and this will get fixed in the next release.
David
If that was the workaround the problem would not be so big. Server time switching to UTC can happen in other (seemingly) unexpected cases long time after an update or restart has been done.
At times like this the Monty Python Lumbar Jack song is an alternative workaround !!!
Everything can be solved by Monty Python, always look on the bright side of life…
On our test-server I can reproduce it, just emptying the java cache of a client and starting the solution again switches the applicationserver time to UTC!!!
Can someone from Servoy please respond whether this is a known bug and whether it will be solved in the next (5.1.5) release.