Board index » jbuilder » Clock changing

Clock changing


2004-06-24 04:15:00 PM
jbuilder19
I am running a java application
under MS windows 2000 (also test on WinXP).
JBuilder X foundation.
I encountered the following phenomena:
1. I run the following code:
static public void main(String args[])
{
while (true)
{
System.out.println("here I am") ;
Thread.sleep(5000) ;
}
}
2. current windows time is 15:00
3. Setting the windows clock to 14:00
4. The thread is not awaking anymore
5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
6. Get the whole wakeups in a row
Is it a know phenomena ?
 
 

Re:Clock changing

Oded Weissman wrote:
Quote
I am running a java application
under MS windows 2000 (also test on WinXP).
JBuilder X foundation.

I encountered the following phenomena:
1. I run the following code:

static public void main(String args[])
{
while (true)
{
System.out.println("here I am") ;
Thread.sleep(5000) ;
}
}

2. current windows time is 15:00
3. Setting the windows clock to 14:00
4. The thread is not awaking anymore
5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
6. Get the whole wakeups in a row

Is it a know phenomena ?

Do you want to explain what problem you are trying to solve? I can't
think of any reason why you would do this.
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
www.google.ca/advanced_group_search
Other Newsgroup Searches:
www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
www.visi.com/~gyles19/fom-serve/cache/1.html
 

Re:Clock changing

"Lori M Olson [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
Oded Weissman wrote:

>I am running a java application
>under MS windows 2000 (also test on WinXP).
>JBuilder X foundation.
>
>I encountered the following phenomena:
>1. I run the following code:
>
>static public void main(String args[])
>{
>while (true)
>{
>System.out.println("here I am") ;
>Thread.sleep(5000) ;
>}
>}
>
>2. current windows time is 15:00
>3. Setting the windows clock to 14:00
>4. The thread is not awaking anymore
>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
>6. Get the whole wakeups in a row
>
>Is it a know phenomena ?
>

Do you want to explain what problem you are trying to solve? I can't
think of any reason why you would do this.

--

Regards,

Lori Olson [TeamB]
1. Changing "daylight saving time".
2. It show that the JVM doesn't work as expected.
BTW: Sun JVM (of JDK 1.4.2) does work as expected.
Oded
Motorola Israel
 

{smallsort}

Re:Clock changing

"Oded Weissman" oded.weissman.motorola.com a écrit :
Quote
"Lori M Olson [TeamB]" < XXXX@XXXXX.COM >wrote:

>Oded Weissman wrote:
>
>
>>I am running a java application
>>under MS windows 2000 (also test on WinXP).
>>JBuilder X foundation.
>>
>>I encountered the following phenomena:
>>1. I run the following code:
>>
>>static public void main(String args[])
>>{
>>while (true)
>>{
>>System.out.println("here I am") ;
>>Thread.sleep(5000) ;
>>}
>>}
>>
>>2. current windows time is 15:00
>>3. Setting the windows clock to 14:00
>>4. The thread is not awaking anymore
>>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
>>6. Get the whole wakeups in a row
>>
>>Is it a know phenomena ?
>>
>
>Do you want to explain what problem you are trying to solve? I can't
>think of any reason why you would do this.
>
>--
>
>Regards,
>
>Lori Olson [TeamB]


1. Changing "daylight saving time".
2. It show that the JVM doesn't work as expected.

BTW: Sun JVM (of JDK 1.4.2) does work as expected.
JB X uses 1.4.2_01, if you use a more recent version add your version as
a JDK then set the JDK of your project to that version...
--
Ludovic
-----------------------------------------
"Les formes qui differencient les etres importent peu
si leur pensees s'unissent pour batir un univers..."
Yoko Tsuno (in 'Les titans' by Roger Leloup)
[The shapes that differenciate beings are not important
if their thoughts unite to build a universe]
 

Re:Clock changing

I changed JDK to 1.4.2_03 (b02) and it didn't help
What is the different between "java" and "javaw" as it look like the only different.
Oded
Motorola Israel
Ludovic HOCHET <personne@nullepart>wrote:
Quote


"Oded Weissman" oded.weissman.motorola.com a écrit :
>"Lori M Olson [TeamB]" < XXXX@XXXXX.COM >wrote:
>
>>Oded Weissman wrote:
>>
>>
>>>I am running a java application
>>>under MS windows 2000 (also test on WinXP).
>>>JBuilder X foundation.
>>>
>>>I encountered the following phenomena:
>>>1. I run the following code:
>>>
>>>static public void main(String args[])
>>>{
>>>while (true)
>>>{
>>>System.out.println("here I am") ;
>>>Thread.sleep(5000) ;
>>>}
>>>}
>>>
>>>2. current windows time is 15:00
>>>3. Setting the windows clock to 14:00
>>>4. The thread is not awaking anymore
>>>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
>>>6. Get the whole wakeups in a row
>>>
>>>Is it a know phenomena ?
>>>
>>
>>Do you want to explain what problem you are trying to solve? I can't
>>think of any reason why you would do this.
>>
>>--
>>
>>Regards,
>>
>>Lori Olson [TeamB]
>
>
>1. Changing "daylight saving time".
>2. It show that the JVM doesn't work as expected.
>
>BTW: Sun JVM (of JDK 1.4.2) does work as expected.
JB X uses 1.4.2_01, if you use a more recent version add your version as
a JDK then set the JDK of your project to that version...

--
Ludovic
-----------------------------------------

"Les formes qui differencient les etres importent peu
si leur pensees s'unissent pour batir un univers..."
Yoko Tsuno (in 'Les titans' by Roger Leloup)
[The shapes that differenciate beings are not important
if their thoughts unite to build a universe]
 

Re:Clock changing

"Oded Weissman" oded.weissman.motorola.com wrote:
Quote
I changed JDK to 1.4.2_03 (b02) and it didn't help

What is the different between "java" and "javaw" as it look like the only different.

Oded
Motorola Israel
java.exe gives you a console. javaw.exe does not.
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
www.google.ca/advanced_group_search
Other Newsgroup Searches:
www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
www.visi.com/~gyles19/fom-serve/cache/1.html
 

Re:Clock changing

Can someone please test the above example and let me know if it recreated ???
is it only metter ot using "Java" insted of "Javaw" ???
Thanks
Oded
 

Re:Clock changing

"Oded wrote:
Quote
>Oded Weissman wrote:
[...]
>>2. current windows time is 15:00
>>3. Setting the windows clock to 14:00
>>4. The thread is not awaking anymore
>>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
1. Changing "daylight saving time".
The sequence of manipulation above is by no means equivalent, or even
has anything particular to do with, the daylight saving time
switchover. That switchover is automatically handled by Windows, and
both Windows itself and the JVM *know* when it'll take place, so they
can maintain the internal time-keeping across this "calendar time"
switch --- they know the correct relation between local time
(including DST) and universal time, and will do all time intervals in
UTC (or an equivalent, e.g. the traditional Unix "number of seconds
since the Epoch").
What you're doing there is more like a sudden change of the location
of the system by one or two hours timezones, which would only make
sense if the machine was actually moved by 1500 or 3000 kilometers in
the blink of an eye. That's a completely unrealistic test case.
Actual time *never* jumps around like that, and certainly not by as
much as a full hour in a single hop. Expecting the system to behave
sensibly is therefore quite a stretch.
Quote
2. It show that the JVM doesn't work as expected.
I fear that's because your expectation is broken.
--
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.
 

Re:Clock changing

You are right. Also one should modify time zone too, not just a current
time to test this situation.
- Alexey.
Hans-Bernhard Broeker wrote:
Quote
"Oded wrote:


>>Oded Weissman wrote:

[...]

>>>2. current windows time is 15:00
>>>3. Setting the windows clock to 14:00
>>>4. The thread is not awaking anymore
>>>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)


>1. Changing "daylight saving time".


The sequence of manipulation above is by no means equivalent, or even
has anything particular to do with, the daylight saving time
switchover. That switchover is automatically handled by Windows, and
both Windows itself and the JVM *know* when it'll take place, so they
can maintain the internal time-keeping across this "calendar time"
switch --- they know the correct relation between local time
(including DST) and universal time, and will do all time intervals in
UTC (or an equivalent, e.g. the traditional Unix "number of seconds
since the Epoch").

What you're doing there is more like a sudden change of the location
of the system by one or two hours timezones, which would only make
sense if the machine was actually moved by 1500 or 3000 kilometers in
the blink of an eye. That's a completely unrealistic test case.
Actual time *never* jumps around like that, and certainly not by as
much as a full hour in a single hop. Expecting the system to behave
sensibly is therefore quite a stretch.


>2. It show that the JVM doesn't work as expected.


I fear that's because your expectation is broken.

 

Re:Clock changing

Why should "Sleep" care about chronical time ???
(only interval is metter - implements by Tick interupts).
Also why using "java" or "javaw" behave differently ???
Oded
Motorola Israel
"Alexey N. Solofnenko" < XXXX@XXXXX.COM >wrote:
Quote
You are right. Also one should modify time zone too, not just a current
time to test this situation.

- Alexey.

Hans-Bernhard Broeker wrote:
>"Oded wrote:
>
>
>>>Oded Weissman wrote:
>
>[...]
>
>>>>2. current windows time is 15:00
>>>>3. Setting the windows clock to 14:00
>>>>4. The thread is not awaking anymore
>>>>5. At 14:02 set windows clock to 16:00 (the thread missed few wakeups)
>
>
>>1. Changing "daylight saving time".
>
>
>The sequence of manipulation above is by no means equivalent, or even
>has anything particular to do with, the daylight saving time
>switchover. That switchover is automatically handled by Windows, and
>both Windows itself and the JVM *know* when it'll take place, so they
>can maintain the internal time-keeping across this "calendar time"
>switch --- they know the correct relation between local time
>(including DST) and universal time, and will do all time intervals in
>UTC (or an equivalent, e.g. the traditional Unix "number of seconds
>since the Epoch").
>
>What you're doing there is more like a sudden change of the location
>of the system by one or two hours timezones, which would only make
>sense if the machine was actually moved by 1500 or 3000 kilometers in
>the blink of an eye. That's a completely unrealistic test case.
>Actual time *never* jumps around like that, and certainly not by as
>much as a full hour in a single hop. Expecting the system to behave
>sensibly is therefore quite a stretch.
>
>
>>2. It show that the JVM doesn't work as expected.
>
>
>I fear that's because your expectation is broken.
>
 

Re:Clock changing

Oded Weissman < XXXX@XXXXX.COM >wrote:
Quote
Why should "Sleep" care about chronical time ???
Because about the only sensible way of implementing a 5-second sleep
without hogging the CPU is to set a timer alarm and put the process to
sleep until it's awoken by that alarm. And the timer is based on
real-world clock time.
I still hold that your test case is a good deal sillier than the JDK's
reaction to it.
Quote
Also why using "java" or "javaw" behave differently ???
Impossible to tell from remote. It's probably some configuration
strangeness of your system. Did you make sure the executables found
under the names "javaw" and "java" come from the same JDK?
--
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.