[JBoss JIRA] (SECURITY-856) org.jboss.security.auth.spi.Util.loadProperties() always uses default properties files
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/SECURITY-856?page=com.atlassian.jira.plug... ]
Chao Wang resolved SECURITY-856.
--------------------------------
Fix Version/s: PicketBox_4_0_21.Beta4
Resolution: Done
PR is merged.
> org.jboss.security.auth.spi.Util.loadProperties() always uses default properties files
> --------------------------------------------------------------------------------------
>
> Key: SECURITY-856
> URL: https://issues.jboss.org/browse/SECURITY-856
> Project: PicketBox
> Issue Type: Bug
> Components: PicketBox
> Affects Versions: PicketBox_4_0_21.Beta3, PicketBox_4_0_19.SP5
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: PicketBox_4_0_21.Beta4
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1073814 Descritpion:
> In case users.properties (and roles.properties) is defined and exists for org.jboss.security.auth.spi.UsersRolesLoginModule then defaultUsers.properties (and defaultRoles.properties) shouldn't be used for this Login Module (according to documentation they should be used only in case usersProperties or rolesProperties file can not be found) but instead of that content of both file is used.
> For reproducing this issue use users.properties with user admin=admin and defaultUsers.properties with admin1=admin1. Both users will be loaded for Login Module but in right behavior only admin user from users.properties should be loaded.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3835) Add missing statistics to Undertow subsystem
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-3835:
------------------------------------
Summary: Add missing statistics to Undertow subsystem
Key: WFLY-3835
URL: https://issues.jboss.org/browse/WFLY-3835
Project: WildFly
Issue Type: Feature Request
Reporter: Stuart Douglas
Assignee: Jason Greene
This includes:
Deployment level session manager statistics:
duplicated-session-ids
expired-sessions
max-active-sessions
rejected-sessions
session-avg-alive-time
session-max-alive-time
Servlet level statistics:
load-time
error-count
Connector level statistics:
bytes-received
bytes-sent
error-count
processing-time
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3828) Backport CLI preference, .jbossclirc
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3828?page=com.atlassian.jira.plugin.... ]
Osamu Nagano deleted WFLY-3828:
-------------------------------
> Backport CLI preference, .jbossclirc
> ------------------------------------
>
> Key: WFLY-3828
> URL: https://issues.jboss.org/browse/WFLY-3828
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Osamu Nagano
> Assignee: Alexey Loubyansky
>
> 1. Proposed title of this feature request
> Backport CLI preference, .jbossclirc
>
> 2. Who is the customer behind the request?
> Account: USSTRATCOM (1018342)
> TAM customer: no
> SRM customer: no
> Strategic: no
>
> 3. What is the nature and description of the request?
> Current CLI can define an alias. For example, {{alias ll="ls -l"}}. But such alias doesn't persist among different CLI sessions. In WildFly, CLI reads ".jbossclirc" during its startup and it can be served to save preferences like aliases.
>
> 4. Why does the customer need this? (List the business requirements here)
> - To avoid typing the same alias every time.
>
> 5. How would the customer like to achieve this? (List the functional requirements here)
> - By defining preferences in ".jbossclirc" file.
>
> 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
> - Start a new CLI session to see whether a defined alias is available or not.
>
> 7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
> https://issues.jboss.org/browse/WFLY-1063
> https://bugzilla.redhat.com/show_bug.cgi?id=1139111
>
> 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
> If possible, in EAP 6.4.
>
> 9. Is the sales team involved in this request and do they have any additional input?
> No.
>
> 10. List any affected packages or components.
> - EAP
>
> 11. Would the customer be able to assist in testing this functionality if implemented?
> No (a customer test is not required).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBJCA-971) convert mbean to adminobject
by Jeff Zhang (JIRA)
[ https://issues.jboss.org/browse/JBJCA-971?page=com.atlassian.jira.plugin.... ]
Jeff Zhang resolved JBJCA-971.
------------------------------
Fix Version/s: 1.2.0.CR1
Resolution: Done
https://github.com/ironjacamar/ironjacamar/pull/229
> convert mbean to adminobject
> ----------------------------
>
> Key: JBJCA-971
> URL: https://issues.jboss.org/browse/JBJCA-971
> Project: IronJacamar
> Issue Type: Task
> Components: AS
> Affects Versions: 1.1.0.Beta3
> Reporter: Jeff Zhang
> Assignee: Jeff Zhang
> Fix For: 1.2.0.CR1
>
>
> <mbean code="org.jboss.resource.deployment.AdminObject"
> name="activemq.queue:name=outboundQueue">
> <attribute name="JNDIName">activemq/queue/outbound</attribute>
> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='activemq-ra.rar'</depends>
> <attribute name="Type">javax.jms.Queue</attribute>
> <attribute name="Properties">PhysicalName=queue.outbound</attribute>
> </mbean>
> maps to
> <admin-object class-name="FIXME"
> jndi-name="activemq/queue/outbound">
> <config-property name="Type">javax.jms.Queue</config-property>
> <config-property name="Properties">PhysicalName=queue.outbound</config-property>
> </admin-object>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (AS7-4710) PersistenceUnitSearch violates the JPA spec
by Anton Rukhlin (JIRA)
[ https://issues.jboss.org/browse/AS7-4710?page=com.atlassian.jira.plugin.s... ]
Anton Rukhlin commented on AS7-4710:
------------------------------------
Thank you, guys!
> PersistenceUnitSearch violates the JPA spec
> -------------------------------------------
>
> Key: AS7-4710
> URL: https://issues.jboss.org/browse/AS7-4710
> Project: Application Server 7
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 7.1.1.Final
> Environment: Linux (Ubuntu, kernel v.3.0.0-12-generic), Java HotSpot SE Runtime Environment (build 1.6.0_31-b04)
> Reporter: Alexander Kiselyov
> Assignee: Scott Marlow
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: persistence-scope-test-ear.zip
>
>
> There is no ability to deploy EAR, which contains several EJB-JAR modules, when more then one of them defining a persistence unit and at least one of EJBs within module "expresses a dependency on a container-managed EntityManager and its associated persistence context" (e.g. using @PersistenceContext annotation) without specifying the unitName.
> Stacktrace during deployment process of such EAR:
> 13:45:36,765 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "persistence-scope-test-ear-ear.ear"
> 13:45:36,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar"
> 13:45:36,794 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar"
> 13:45:36,886 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011401: Read persistence.xml for primary
> 13:45:36,889 INFO [org.jboss.as.jpa] (MSC service thread 1-4) JBAS011401: Read persistence.xml for primary
> 13:45:36,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
> at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> 13:45:36,899 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
> at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> Issue is related to the AS7-2275 (https://issues.jboss.org/browse/AS7-2275).
> JPA 2.0 specification (in paragraph "8.2.2 Persistence Unit Scope") states that:
> "When referencing a persistence unit using the unitName annotation element or persistence-
> unit-name deployment descriptor element, the visibility scope of the persistence unit is
> determined by its point of definition:
> • A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is
> scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components
> defined in that jar or war."
> Although it says "when referencing... using the unitName", when in this case "unitName" attribute is omitted, I believe this (taking into account persistence units defined in other modules) is still a bug, cause:
> 1. The scope of a persistence unit is all the same implied by the spec, e.g. by sentences like this: "The persistence.xml file may be used to designate more than one persistence unit within the same scope. The persistence.xml file may be used to designate more than one persistence unit within the same scope."
> 2. AFAIK, neither JPA 2.0 nor EJB 3.1 specification defines any persistence unit choosing algorithm in case of unitName omission despite this attribute is optional.
> Code responsible for generating an aforementioned exception resides in org.jboss.as.jpa.container.PersistenceUnitSearch:
>
> PersistenceUnitsInApplication persistenceUnitsInApplication = DeploymentUtils.getTopDeploymentUnit(deploymentUnit).getAttachment(PersistenceUnitsInApplication.PERSISTENCE_UNITS_IN_APPLICATION);
>
> if (persistenceUnitsInApplication.getCount() > 1) {
>
> // AS7-2275 no unitName and there is more than one persistence unit;
>
> throw MESSAGES.noPUnitNameSpecifiedAndMultiplePersistenceUnits(persistenceUnitsInApplication.getCount(),DeploymentUtils.getTopDeploymentUnit(deploymentUnit));
>
> }
> So, since a developer haven't defined any EAR-level persistence unit ant tries to inject EntityManager without using the unitName - all persistence unit defined in other EJB/WAR modules are taken into account and application is prevented from deploying because of "false ambiguity".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3834) Memory leak in org.xnio.ByteBufferSlicePool
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3834?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3834:
------------------------------
Affects Version/s: 8.1.0.Final
> Memory leak in org.xnio.ByteBufferSlicePool
> -------------------------------------------
>
> Key: WFLY-3834
> URL: https://issues.jboss.org/browse/WFLY-3834
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Sergey Lisovoy
> Labels: memory_leak, memoryleak
>
> I have a simple thread that monitor remote wildfly process status. After some time it fail with OutOfMemory exception.
> I wrote simple exsample how to reproduce its error:
> {code:java}
> package ru.kamis.tests.xniomemoryleaks;
> import org.jboss.as.controller.client.ModelControllerClient;
> import org.jboss.as.controller.client.helpers.Operations;
> import org.jboss.dmr.ModelNode;
> public class OutOfMemoryDemo {
> public static void main(String[] args) throws Exception {
>
> for(int i=0; i<1000000; i++) {
> ModelControllerClient client = null;
> client = ModelControllerClient.Factory.create("localhost", 9990);
>
> ModelNode operation = Operations.createReadAttributeOperation(new ModelNode().setEmptyList(), "server-state");
> client.execute(operation);
>
> client.close();
>
> if(i % 1000 == 0) {
> System.out.println("Processed: " + i);
> }
> }
> }
> }
> {code}
> Program produces folowing output:
> {noformat}
> сен 09, 2014 2:33:20 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.3.Final
> Processed: 0
> Processed: 1000
> Processed: 2000
> Processed: 3000
> Processed: 4000
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.lang.String.toCharArray(String.java:2746)
> at sun.net.www.ParseUtil.encodePath(ParseUtil.java:107)
> at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:757)
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:842)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:15)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> сен 09, 2014 2:35:20 PM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> WARN: JBAS010600: Closing leaked controller client
> JBAS010649: Allocation stack trace:
> at java.lang.Thread.getStackTrace(Thread.java:1589)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:353)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:200)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:12)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> {noformat}
> Used libraries:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-controller-client</artifactId>
> <version>8.1.0.Final</version>
> </dependency>
> {code}
> The same bug is reproduced on other xnio versions: 3.2.3.Final, 3.3.0.Beta2
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[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 commented on JGRP-1877:
--------------------------------
Probably better to pass a {{TimeUnit}} to the method
> 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, 1 month
[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/9/14 12:27 PM:
---------------------------------------------------------
Code using the return value of {{Condition.awaitNanos()}}:
{code:java}
public boolean waitFor(long timeout) {
boolean intr=false;
final long timeout_ns=TimeUnit.NANOSECONDS.convert(timeout,TimeUnit.MILLISECONDS);
lock.lock();
try {
for(long wait_time=timeout_ns, start=System.nanoTime(); !done && wait_time > 0;) {
try {
wait_time=cond.awaitNanos(wait_time);
}
catch(InterruptedException e) {
wait_time=timeout_ns - (System.nanoTime() - start);
intr=true;
}
}
return done;
}
finally {
lock.unlock();
if(intr) Thread.currentThread().interrupt();
}
}
{code}
was (Author: belaban):
Code using the return value of {{Condition.awaitNanos()}}:
{code:java}
public boolean waitFor(long timeout) {
boolean intr=false;
final long timeout_ns=TimeUnit.NANOSECONDS.convert(timeout,TimeUnit.MILLISECONDS);
lock.lock();
try {
for(long wait_time=timeout_ns, start=System.nanoTime(); !done && wait_time > 0; /*wait_time=timeout_ns - (System.nanoTime() - start)*/) {
try {
System.out.println("wait(" + TimeUnit.MILLISECONDS.convert(wait_time,TimeUnit.NANOSECONDS) + ")");
wait_time=cond.awaitNanos(wait_time);
}
catch(InterruptedException e) {
wait_time=timeout_ns - (System.nanoTime() - start);
intr=true;
}
}
return done;
}
finally {
lock.unlock();
if(intr) Thread.currentThread().interrupt();
}
}
{code}
> 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, 1 month
[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 commented on JGRP-1877:
--------------------------------
Code using the return value of {{Condition.awaitNanos()}}:
{code:java}
public boolean waitFor(long timeout) {
boolean intr=false;
final long timeout_ns=TimeUnit.NANOSECONDS.convert(timeout,TimeUnit.MILLISECONDS);
lock.lock();
try {
for(long wait_time=timeout_ns, start=System.nanoTime(); !done && wait_time > 0; /*wait_time=timeout_ns - (System.nanoTime() - start)*/) {
try {
System.out.println("wait(" + TimeUnit.MILLISECONDS.convert(wait_time,TimeUnit.NANOSECONDS) + ")");
wait_time=cond.awaitNanos(wait_time);
}
catch(InterruptedException e) {
wait_time=timeout_ns - (System.nanoTime() - start);
intr=true;
}
}
return done;
}
finally {
lock.unlock();
if(intr) Thread.currentThread().interrupt();
}
}
{code}
> 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, 1 month