org.jboss.varia.scheduler.Scheduler Problem ?

[fdomino]

Hi there,

Got a problem ( or maybe a misunderstanding) and wonder if you can help me.

We use jbossAS 4.0.3 - Sp1
Eclipse ide, but personally i just think its a scheduler issue

I'm located in Germany
now to my question:


if A seperate schedulerMbean is added with this code:

<mbean code="org.jboss.varia.scheduler.Scheduler"
 name=":service=Scheduler,name=ServiceScheduler">

 <attribute name="StartAtStartup">true</attribute>


 <attribute name="SchedulableMBeanMethod">
 perform(DATE, REPETITIONS)
 </attribute>
 <attribute name="DateFormat">dd/MM/yyyy-hh:mm:ss</attribute>
 <attribute name="InitialStartDate">01/01/2007-3:45:00</attribute>
 <attribute name="SchedulePeriod">86400000</attribute>
 <attribute name="InitialRepetitions">-1</attribute>

 </mbean>

how do i fix the problem that with the resetting calendar to summer time where there is an hour difference ?

i did get this pattern :

before summertime change -> correct usage of time InitialDate and schedulePeriod
after summertime change -> incorrect usage of time InitialDate and SchedulePeriod
the date is set correctly but somehow the period is added wrong.
After summertime change the perform - Date is moved to 4:45 (One hour later , just the time that is used to differenciate between winter time and summer time !)

i've looked up some issues in jira and found one where there is a solution but its not yet marked "fixed in version"
(The solution are the dynamic keywords "NOW" & "TOMORROW" )
http://jira.jboss.com/jira/browse/JBAS-2596

Hope my english is not that bad

Any ideas ?
Thanks in advance

[potschta]

Hello,
I have now the same problem like you - did you find a solution already? Please answer. Thank you.

[fdomino]

Hi,

nope , only solution to us right now are our company release cycles in which we change the initialStartDate to summer/winter time.

But if there is another solution i'm happy to try :-)

[jaikiran]

Based on what you explain, this appears to be the issue in the JDK/JRE that you are using. Does it have the patch for the DST? Which version of Java do you use? Post the output of:

java -version

You can even post the contents of boot.log (in %JBOSS_HOME%\server\< serverName>\log folder).

[fdomino]

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

JBoss 4.2.1 GA do we use..

[jaikiran]

Which area is the server located in? This table http://java.sun.com/javase/timezones/tzdata_versions.html lists down the JRE versions which contain the fixes for various regions. For example, the table there mentions that the JRE version 6u5 (Jave 6 Update 5) takes care of :

New data for Argentina: at 2am local time on December 29, 2007, the DST offset moved from GMT-4 to GMT-5.

Also, did you try to upgrade to the latest JRE version (Java SE 6 Update 10 RC)? Do you see the same issue there?

[fdomino]

nope ... we are located in Germany ... and the server too

the time this problem arose , there was no higher update available....
but I will try it in a few weeks , but its strange
that it looks like that the schedulePeriod is just added.... and not maybe converted...
well i dont know :/

.... this issue isnt a high priority its just a curious occurrence

[potschta]

I just overwrite the initialStartDate-Method of org.jboss.varia.scheduler.Scheduler and correct the time myself, if we have now summer time and the orgininal initial start date is winter time or vice versa. Not a fine solution, but one.

[fdomino]

Maybe you should submit your solution to jboss.org :-)

if its a valid solution it will be implemented.

But as far as I'm concerned , very good Idea ... i think i'll do that too

[jaikiran]

"FDomino" wrote:
but its strange
that it looks like that the schedulePeriod is just added.... and not maybe converted...

<attribute name="SchedulePeriod">86400000</attribute>

Though i haven't completely seen how its behaving on your system (i mean at what "time" the timer is triggered), i think i know what the problem is.

The problem lies in the value being passed to SchedulePeriod. 86400000 milli seconds form 1 day. But on the day when the DST is applied, adding 86400000 to the time is not equivalent to adding 1 day to the date. Here's an example - I have access to a system hosted in US (Pacific Standard Time). This year (2008) the daylight saving time began on March 9 at 2 AM. So in our example, lets start with the date as March 9, 1 AM. The example below,

- first adds 86400000 milli seconds to March 9, 1 AM. The intention is to get the output date as March 10, 1 AM. However as you see in the output, that i have posted below, the output date is Mar 10, 2 AM. Which is not what i wanted.

- Later, instead of adding 86400000 milli seconds, i add 1 day using Calendar.DATE, to the original date March 9, 1 AM. Again, the intention is to get output date as March 10, 1 AM. As shown in the output, this works. So because of the DST, 1 day is not equal to 86400000 milli seconds on March 9.

There's a way to figure out the offset in milliseconds because of the DST. So when adding the 86400000 milli seconds to increment by a day, you should take into account, this offset. See my comments in the code below which does this. When this offset is considered, the output date is as expected March 10, 1 AM.

package org.myapp;

import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.Properties;
import java.util.TimeZone;

public class DateUtility {

 /**
 * @param args
 */
 public static void main(String[] args) {
 try {

 Calendar calendar = new GregorianCalendar();
 TimeZone tz = calendar.getTimeZone();
 System.out.println("Timezone is " + tz.getDisplayName());
 System.out.println("Amount of time to be added because of DST " + tz.getDSTSavings() + " milli sec");
 DateFormat df1 = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

 Date originalDate = df1.parse("2008-03-09 01:00:00.000");
 calendar.setTime(originalDate);
 System.out.println("Original date is " + calendar.getTime());

 // Jaikiran: Adding 86400000 milli seconds to increment by one day
 // does NOT work
 // Add 86400000 milli seconds and display the output
 calendar.add(Calendar.MILLISECOND,86400000);
 System.out.println("Date after adding 86400000 milli sec to original date is " + calendar.getTime());

 // Reset to original date
 calendar.setTime(originalDate);

 // Jaikiran: Adding 1 day through Calendar.DATE works
 // Now add 1 day and display the output
 calendar.add(Calendar.DATE,1);
 System.out.println("Date after adding 1 day to original date is " + calendar.getTime());

 // Reset to original date
 calendar.setTime(originalDate);

 // Jaikiran: Take into consideration the DST offset and then add the milli seconds.
 // This works.
 // Now add (86400000 milli seconds - tz.getDSTSavings() ) and display the output
 calendar.add(Calendar.MILLISECOND,86400000 - tz.getDSTSavings());
 System.out.println("Date after adding (86400000-" + tz.getDSTSavings() + ") = " + (86400000 - tz.getDSTSavings()) + " milli sec to original date is " + calendar.getTime());


 } catch (Exception e) {
 e.printStackTrace();
 }
 }

}

The output of this code:

Timezone is Pacific Standard Time
Amount of time to be added because of DST 3600000 milli sec
Original date is Sun Mar 09 01:00:00 PST 2008
Date after adding 86400000 milli sec to original date is Mon Mar 10 02:00:00 PDT 2008
Date after adding 1 day to original date is Mon Mar 10 01:00:00 PDT 2008
Date after adding (86400000-3600000) = 82800000 milli sec to original date is Mon Mar 10 01:00:00 PDT 2008

So to handle this efficiently, either

- The org.jboss.varia.scheduler.Scheduler should be enhanced to accept a string value like "DAILY" for the SchedulePeriod attribute. This will shield the user from passing the correct milli seconds value for a day.

OR

- The user who configures the scheduler xml, should be smart enough to know the effect of DST and then decide what value to pass to the SchedulePeriod.

[fdomino]

@Jaikiran,

exactly , there lies the problem, maybe I wrote it a little too complicated ( I do that too often) but you got the idea
.. a daily attribute would be perfect...

yeah , i think in configuring the scheduler.xml ( or jboss-service.xml as in our part) is a little bit "foggy" , cause the documentation is not clear enough on the schedulePeriod subject

[jaikiran]

I haven't used JBoss scheduler in any of my projects and i don't know if this issue is observed by many other users. I guess, this issue will be observed on any system with has DST patching. I could not find a JIRA related to this. If this is a common problem, should a JIRA be opened?

[fdomino]

There is an Issue already open but it has to do with the startdate param

https://jira.jboss.org/jira/browse/JBAS-2596

Yes a issue would be very much appreciated ;)
The Issue should be a simple one ( add parameters like daily,monthly hourly and so on ) , shouldn't it?