[JBoss JIRA] (WFLY-3841) double :remove of connection-property from a DS leave it in wrong state
by Stefano Maestri (JIRA)
Stefano Maestri created WFLY-3841:
-------------------------------------
Summary: double :remove of connection-property from a DS leave it in wrong state
Key: WFLY-3841
URL: https://issues.jboss.org/browse/WFLY-3841
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Stefano Maestri
Assignee: Stefano Maestri
Priority: Critical
Fix For: 9.0.0.CR1
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:add(value=foo)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload
{
"outcome" => "success",
"result" => undefined
}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.data-source-config.ExampleDS.connection-properties.foo was depended upon by service jboss.data-source-config.ExampleDS",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool
{
"outcome" => "failed",
"failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/ExampleDS",
"rolled-back" => true
}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/10/14 10:10 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* Request (UnicastRequest, GroupRequest)
* MessageDispatcher / RpcDispatcher: sync RPCs
* ExpiryCache
* TimeService
* Discovery: ping responses
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* Request (UnicastRequest, GroupRequest)
* MessageDispatcher / RpcDispatcher: sync RPCs
* ExpiryCache
* TimeService
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/10/14 10:08 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* Request (UnicastRequest, GroupRequest)
* MessageDispatcher / RpcDispatcher: sync RPCs
* ExpiryCache
* TimeService
was (Author: belaban):
Investigate:
- Responses
- Request (UnicastRequest, GroupRequest)
- MessageDispatcher / RpcDispatcher: sync RPCs
- ExpiryCache
- TimeService
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-540) KieModule fails to load on Windows
by Marek Siller (JIRA)
[ https://issues.jboss.org/browse/DROOLS-540?page=com.atlassian.jira.plugin... ]
Marek Siller commented on DROOLS-540:
-------------------------------------
I have created a patch for this issue - both for the master branch and for 6.1.x branch.
> KieModule fails to load on Windows
> ----------------------------------
>
> Key: DROOLS-540
> URL: https://issues.jboss.org/browse/DROOLS-540
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Environment: Windows 2007, Weblogic 12c
> Reporter: Christian Sterzl
> Assignee: Mark Proctor
>
> When loading a KModule in Weblogic on Windows it fails.
> The error is in this class:
> {code:java|title=org.drools.compiler.kie.builder.impl.ClasspathKieProject|linenumbers=true|firstline=300}
> // remove any remaining protocols, normally only if it was a jar
> int firstSlash = urlPath.indexOf( '/' );
> colonIndex = firstSlash > 0 ? urlPath.lastIndexOf( ":", firstSlash ) : urlPath.lastIndexOf( ":" );
> if ( colonIndex >= 0 ) {
> urlPath = urlPath.substring( colonIndex + 1 );
> }
> {code}
> Following input:
> /C:/DEV_DATA/Workspaces/BDD/taskboard.rules/target/classes
> Produces following output:
> /DEV_DATA/Workspaces/BDD/taskboard.rules/target/classes
> Which makes it impossible to load in a windows environment.
> When I add the pom.properties on the same drive as Weblogic runs it works.
> I have to add pom.properties on D:/DEV_DATA/Workspaces/BDD/taskboard.rules/target/classes/META-INF/maven/classes/pom.properties.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-354) Can't load pom.properties when jar not on default drive on Windows
by Marek Siller (JIRA)
[ https://issues.jboss.org/browse/DROOLS-354?page=com.atlassian.jira.plugin... ]
Marek Siller commented on DROOLS-354:
-------------------------------------
I have created a patch for this issue - both for the master branch and for 6.1.x branch.
> Can't load pom.properties when jar not on default drive on Windows
> ------------------------------------------------------------------
>
> Key: DROOLS-354
> URL: https://issues.jboss.org/browse/DROOLS-354
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Environment: Windows
> Reporter: Peter Cooper
> Assignee: Mark Proctor
>
> I'm using Apache Tomcat to run my web application, which includes Drools 6.0.0.Final and getting rules files out of the classpath. However, the webapps directory (the appBase in Tomcat's server.xml) is on a different drive than the main Tomcat installation. When Drools is trying to get its pom properties (ClasspathKieProject's getPomProperties method, starting on line 167) it looks like it first strips off the Windows drive letter. It then tries to find the path, but on the drive of the Windows current directory (in this case, the drive where Tomcat is installed) instead of the drive where the file actually is. This means that it can't find the jar file, so I get the "Unable to load pom.properties" "as jarPath cannot be found" error. I'm not sure why it's trying to strip off the drive letter, since I think it would be able to find the file correctly if that weren't the case.
> Thank you.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2376:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from NEW to ASSIGNED
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
> Key: WFLY-2376
> URL: https://issues.jboss.org/browse/WFLY-2376
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
> ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)"
> "stale-connection-checker-properties" => {
> "type" => OBJECT,
> "description" => "The stale connection checker properties",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "reauth-plugin-properties" => {
> "type" => OBJECT,
> "description" => "The properties for the reauthentication plugin",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "exception-sorter-properties" => {
> "type" => OBJECT,
> "description" => "The exception sorter properties",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
> ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
> <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
> <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
> <driver>ojdbc6.jar</driver>
> <new-connection-sql>select 1 from dual</new-connection-sql>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
> <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
> </validation>
> </datasource>
> ${quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-1968) Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1968?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1968:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> changed the Status of [bug 991389|https://bugzilla.redhat.com/show_bug.cgi?id=991389] from NEW to CLOSED
> Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1968
> URL: https://issues.jboss.org/browse/WFLY-1968
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Vladimir Rastseluev
> Assignee: Stefano Maestri
> Fix For: 9.0.0.Beta1
>
>
> Description of problem:
> Start server with configured resource adapter and deployed generic-jms-ra.rar. After server started we can see registered and bound connection factory.
> Then we add some changes to the server to set up jts transactions mode by CLI utility. Reload the server. Connection factory isn't registered.
> Version-Release number of selected component (if applicable):
> EAP 6.1.1.ER4
> generic resource adapter: https://github.com/jbertram/generic-jms-ra
> How reproducible:
> easy
> Steps to Reproduce:
> 1. add applied generic-jms-ra.rar file to the $JBOSS_HOME/standalone/deployments directory
> 2. unpack applied module and add it to $JBOSS_HOME/modules directory
> 3. update module.xml file from org.jboss.as.ee module, adding a new dependency:
> "<module name="com.tibco.tibjms"/>"
> 4. update $JBOSS_HOME/standalone/configuration/standalone.xml, adding global modules to <subsystem xmlns="urn:jboss:domain:ee:1.1">:
> <global-modules>
> <module name="com.tibco.tibjms" slot="main"/>
> <module name="org.jboss.common-core" slot="main"/>
> </global-modules>
> 5.configure resource-adapters subsystem this way:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
> <resource-adapters>
> <resource-adapter id="generic-jms-ra.rar">
> <archive>
> generic-jms-ra.rar
> </archive>
> <transaction-support>XATransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.jboss.resource.adapter.jms.JmsManagedConnectionFactory" jndi-name="java:/jms/QueueConnectionFactory" pool-name="CF" use-java-context="false">
> <config-property name="JndiParameters">
> java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://tibco01.mw.lab.eng.bos.redhat.com:7222
> </config-property>
> <config-property name="ConnectionFactory">
> XAQCF
> </config-property>
> <security>
> <application/>
> </security>
> <recovery>
> <recover-credential>
> <user-name>tibco</user-name>
> <password>tibco</password>
> </recover-credential>
> </recovery>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> </subsystem>
> 6. run server $JBOSS_HOME/bin/standalone.sh
> see - java:/jms/QueueConnectionFactory is registered
> 7. run $JBOSS_HOME/bin/cli.sh
> 8. execute commands in cli:
> -->/subsystem=jacorb/:write-attribute(name=transactions,value=on)
> -->/subsystem=transactions/:write-attribute(name=recovery-listener,value=true)
> -->/subsystem=transactions/:write-attribute(name=jts,value=true)
> -->:reload
> Actual results:
> connection factory java:/jms/QueueConnectionFactory isn't registered
> Expected results:
> connection factory java:/jms/QueueConnectionFactory is registered
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (AS7-6104) jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6104?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6104:
----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> changed the Status of [bug 928979|https://bugzilla.redhat.com/show_bug.cgi?id=928979] from NEW to ASSIGNED
> jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6104
> URL: https://issues.jboss.org/browse/AS7-6104
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Professional SP1
> Reporter: Raymond Naseef
> Assignee: Brian Stansberry
> Labels: jboss-as7, modules, postgresql
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> NullPointerException during jboss-cli remove with command:
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=bop:remove"
> Console and log below.
> This happens when standalone.xml has XML entry for driver that does not exist (see "Steps to Reproduce"). I have also seen this happen in a case where the driver does exist; not sure how the latter happened, or how important that is.
> MS-DOS Console:
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> Server Log:
> 23:17:42,627 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 19) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "postgresql-driver")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.doRemove(OperationContextImpl.java:298) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.OperationContextImpl.removeService(OperationContextImpl.java:293) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.connector.subsystems.datasources.JdbcDriverRemove.performRuntime(JdbcDriverRemove.java:66)
> at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1881) TimeService: provide time on request
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1881?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1881:
--------------------------------
I benched calling {{System.nanoTime()}} and {{System.currentTimeMillis()}} 20 million times, and the 2 calls took about the same time. The above therefore doesn't make any sense: if it takes a {{nanoTime()}} call to measure oldness every time we call TimeService, then the point of having the current wall clock time cached is moot.
Closing this ticket.
> TimeService: provide time on request
> ------------------------------------
>
> Key: JGRP-1881
> URL: https://issues.jboss.org/browse/JGRP-1881
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> Currently the TimeService registers a task that runs every (say) 500 ms. It gets the current time and updates a field. Threads which get the time from the TimeService get the value of that field, so {{System.currentTimeMillis()}} is not called too much.
> However, when no thread needs to get the time for a period of time, the TimeService nevertheless calls {{System.currentTimeMillis()}} every 500 ms, and we have an additional task in the timer.
> h5. SOLUTION
> * Remove that task which periodically gets the current time
> * Add a {{timestamp}} field ({{System.nanoTime()}}) which gets set when {{System.currentTimeMillis()}} is called
> * Add a field {{current_time}} which is set by {{System.currentTimeMillis()}}
> * When a thread wants to get the current time from the TimeService, it compares the current time with the timestamp and, if 500 ms have elapsed, calls {{System.currentTimeMillis()}}, sets the timestamp and current_time fields and returns the time
> * If the time elapsed since the last update is less than 500 ms, it returns {{current_time}}
> There has to be synchronization around getting the current time ({{System.currentTimeMillis()}}), but this could be done with a CAS and a busy loop.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1881) TimeService: provide time on request
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1881?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1881.
--------------------------
Resolution: Won't Fix
> TimeService: provide time on request
> ------------------------------------
>
> Key: JGRP-1881
> URL: https://issues.jboss.org/browse/JGRP-1881
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> Currently the TimeService registers a task that runs every (say) 500 ms. It gets the current time and updates a field. Threads which get the time from the TimeService get the value of that field, so {{System.currentTimeMillis()}} is not called too much.
> However, when no thread needs to get the time for a period of time, the TimeService nevertheless calls {{System.currentTimeMillis()}} every 500 ms, and we have an additional task in the timer.
> h5. SOLUTION
> * Remove that task which periodically gets the current time
> * Add a {{timestamp}} field ({{System.nanoTime()}}) which gets set when {{System.currentTimeMillis()}} is called
> * Add a field {{current_time}} which is set by {{System.currentTimeMillis()}}
> * When a thread wants to get the current time from the TimeService, it compares the current time with the timestamp and, if 500 ms have elapsed, calls {{System.currentTimeMillis()}}, sets the timestamp and current_time fields and returns the time
> * If the time elapsed since the last update is less than 500 ms, it returns {{current_time}}
> There has to be synchronization around getting the current time ({{System.currentTimeMillis()}}), but this could be done with a CAS and a busy loop.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years