Hi Johan,
Is there any news on this issue? The timezone is being changed quite frequently on our system due to connecting Smart Clients. We are also running a booking system on the same server (Servoy 5.1.4) which is open to the world and this issue is giving us quite some problems.
Vincent,
you have to upgrade to 5.2 to get this fix, 5.1.4 was the last for the 5.1.x, its replaced by 5.2
I am having a related problem in 5.2.11 build 1022. I have a table with a creation_date column that is set to auto-enter creation server datetime. The solution that inserts into this table is running as a batch process. This is a very active table (called ‘packets’) in which records are being added constantly (about 90 per minute). The timestamp works, but about once every ten days or so, it stamps a few records in a row with the a timestamp that has reverted to GMT time (insteald of GMT-7, which is what the server is currently set to). Then it goes back to the correct timezone. This has happened about 6 times now.
It only affects this one table, even though there are often insertions being made in other tables at the same time, by the same solution.
The database is Sybase SQL Anywere v11. Here is the other environment info:
Server Information
Servoy version 5.2.11 -build 1022
Port used by RMI Registry: 1099
Repository version 38 (4dd689c6-8de2-4a01-816c-e79ae226a623)
Current time: Fri Jun 08 23:44:19 PDT 2012
Uptime: 6 hours 13 minutes 8 seconds
Server ID: A0DF9CC1-288C-4C33-A7B1-CDD080095B08User Information
Logged in as: amcgillyJVM Information
java.vm.name=Java HotSpot™ 64-Bit Server VM
java.version=1.6.0_31
java.vm.info=mixed mode
java.vm.vendor=Apple Inc.Operating System Information
os.name=Mac OS X
os.version=10.6.8
os.arch=x86_64System Information
Heap memory: allocated=66292K, used=36931K, max=258880K
None Heap memory: allocated=99952K, used=61748K, max=180224K
Dump the current stack/systeminfo
Any suggestions would be appreciated. Thank you.
We came across, that when we updating a plugin or bean, and after that, the first client downloads the client, the server jumps to GMT-0, when the server is busy repacking all the jars…
So what we now always do, after we released new plugins, libs and beans, is download directly the client, so the server starts repacking the jars.
after repacking the server jumps back to your default GMT (in hour case: GMT+1)
I have discussed this with Johan, en he said, they could’nt change that easily because of how pack2000 (or some other lib) works
Thanks Harjo but I think this is a different, though perhaps related, problem. In my case, based on these auto-entered creation dates I’m getting in this one table, the server timestamp is jumping from GMT-7 to GMT-0 for just a couple seconds and then going back to GMT-7 all by itself. And we definitely haven’t updated any plugins or beans recently.
but that sounds exactly what harjo describes
That something is setting it to GMT-0 for a moment and then back.
That is exactly how Pack200 works when it packs the jars
OK. But then something other than updating beans and plugins must be causing this because I have NOT touched the beans or plugins on this server since this started happening.
amcgilly:
OK. But then something other than updating beans and plugins must be causing this because I have NOT touched the beans or plugins on this server since this started happening.
But did this happens once or constantly? Do you still see it happening?
Maybe somehow a new client was started that somehow ticked a specific jar to pack it once
I don’t know anything else that could cause the quick jump to timezone 0 and back to the normal one on the server.
It happened on these dates (Day/Month): 2/4, 17/4, 28/4, 18/5, 11/6.
I know this because we have a batch processor running 24/7 on a separate server that polls the packets table every 5 mins to make sure new packet records are coming into the db at all times. (The plan is to eventually move this server off-site so we have an independent db monitoring capability) Once this timestamp problem started happening I programmed this monitoring process to send me an email alert if it detects a creation date that is set in the future. Each time it sent me an alert I looked in the table and confirmed that there were 3 to 5 records (over a period of about 1 or 2 seconds) that had creation-date timestamps in GMT-0. Records created before and after were correctly set to GMT-7.
The only possible connection to the updating of plugins that I can see is this:
We have a Test environment and a Production environment. Each consists of its own machine, Servoy Server and Sybase SQL Anywhere server.
The packets records which are getting the bad timestamps are being continuously written to the Production DB by a batch process running on the Production server.
The poller I mentioned above which monitors the packets table is currently running on the TEST server but it is polling the production DB. It does NOT write to the production DB, it only queries it, using getDataSetByQuery. See the illustration below.
We HAVE periodically been updating plugins on the TEST server. Do you see any way that could be affecting the production server in this way? I realize it is unorthodox to have two Servoy Servers connecting to the same DB, but as only one of them is writing to the db, and the other is just doing SQL queries I didn’t think it would be a problem.
[attachment=0]arch.JPG[/attachment]
This is still happening. About once a week I have to go in and manually adjust the creation_date columns for a handful of records where the creation date was improperly Auto-Entered by a batch process running on the server. The creation dates are being recorded in UTC time instead of the server’s timezone (UTC-7), but just for a couple records, then it goes back to UTC-7 for subsequent records. Not pattern I can detect as to when or why this is happening. Very annoying. Does Servoy have any suggestions for me?
Server Information
Servoy version 5.2.14 -build 1027
Port used by RMI Registry: 1099
Repository version 38 (4dd689c6-8de2-4a01-816c-e79ae226a623)
Current time: Wed Sep 05 11:45:00 PDT 2012
Uptime: 6 days 18 hours 26 minutes 35 seconds
Server ID: 2A03C5EF-7FC5-4E4C-A005-D0622492501B
JVM Information
java.vm.name=Java HotSpot™ 64-Bit Server VM
java.version=1.6.0_33
java.vm.info=mixed mode
java.vm.vendor=Apple Inc.
Operating System Information
os.name=Mac OS X
os.version=10.6.8
os.arch=x86_64
System Information
Heap memory: allocated=517760K, used=389621K, max=517760K
None Heap memory: allocated=150916K, used=102464K, max=180224K
the only thing that i know of is that the server time does change to UTC is when packing jars, so when you download for the first time the complete smart client from a server after a server had some updates (itself or plugins)
after that i have no idea how this can happen in servoy code.
