You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Adam Walczak (JIRA)" <ji...@apache.org> on 2009/11/22 13:29:53 UTC
[jira] Created: (AMQ-2504) Synchronize time without modifying the
system date.
Synchronize time without modifying the system date.
---------------------------------------------------
Key: AMQ-2504
URL: https://issues.apache.org/activemq/browse/AMQ-2504
Project: ActiveMQ
Issue Type: Improvement
Components: JMS client
Reporter: Adam Walczak
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
Scenario:
1. Servers system date is sync'ed with an NTP server.
2. Clients retrieve their time difference from the NTP server
3. The client set ActiveMq...setTimeDifferenceToServer(...)
4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2504) Synchronize time without modifying the
system date.
Posted by "Adam Walczak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Walczak updated AMQ-2504:
------------------------------
Description:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
Scenario:
1. Servers system date is sync'ed with an NTP server.
2. Clients retrieve their time difference from the NTP server
3. The client set ActiveMq...setTimeDifferenceToServer(...)
4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
was:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
Scenario:
1. Servers system date is sync'ed with an NTP server.
2. Clients retrieve their time difference from the NTP server
3. The client set ActiveMq...setTimeDifferenceToServer(...)
4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> Synchronize time without modifying the system date.
> ---------------------------------------------------
>
> Key: AMQ-2504
> URL: https://issues.apache.org/activemq/browse/AMQ-2504
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Adam Walczak
>
> I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
> Scenario:
> 1. Servers system date is sync'ed with an NTP server.
> 2. Clients retrieve their time difference from the NTP server
> 3. The client set ActiveMq...setTimeDifferenceToServer(...)
> 4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2504) Synchronize time without modifying the
system date.
Posted by "Bruce Snyder (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruce Snyder updated AMQ-2504:
------------------------------
Fix Version/s: 5.5.0
(was: 5.4.1)
> Synchronize time without modifying the system date.
> ---------------------------------------------------
>
> Key: AMQ-2504
> URL: https://issues.apache.org/activemq/browse/AMQ-2504
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Adam Walczak
> Fix For: 5.5.0
>
>
> I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
> Scenario:
> 1. Servers system date is sync'ed with an NTP server.
> 2. Clients retrieve their time difference from the NTP server
> 3. The client set ActiveMq...setTimeDifferenceToServer(...)
> 4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> I think it also would be an good idea to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2504) Synchronize time without modifying the
system date.
Posted by "Adam Walczak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Walczak updated AMQ-2504:
------------------------------
Description:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
Scenario:
1. Servers system date is sync'ed with an NTP server.
2. Clients retrieve their time difference from the NTP server
3. The client set ActiveMq...setTimeDifferenceToServer(...)
4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
I think it also would be an good idea to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
was:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
Scenario:
1. Servers system date is sync'ed with an NTP server.
2. Clients retrieve their time difference from the NTP server
3. The client set ActiveMq...setTimeDifferenceToServer(...)
4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
> Synchronize time without modifying the system date.
> ---------------------------------------------------
>
> Key: AMQ-2504
> URL: https://issues.apache.org/activemq/browse/AMQ-2504
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Adam Walczak
>
> I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
> Scenario:
> 1. Servers system date is sync'ed with an NTP server.
> 2. Clients retrieve their time difference from the NTP server
> 3. The client set ActiveMq...setTimeDifferenceToServer(...)
> 4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> I think it also would be an good idea to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.