[JBoss JIRA] (JBMESSAGING-1955) Deadlock on failover with client lease
by Doug Grove (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1955?page=com.atlassian.jira.... ]
Doug Grove reassigned JBMESSAGING-1955:
---------------------------------------
Assignee: Doug Grove
> Deadlock on failover with client lease
> --------------------------------------
>
> Key: JBMESSAGING-1955
> URL: https://issues.jboss.org/browse/JBMESSAGING-1955
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Messaging Core Distributed Support
> Affects Versions: 1.4.8.SP5
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Doug Grove
>
> JBoss is configured as an 8 node cluster. This cluster is for JMS messaging only. Other JBoss instances host MDBs. When failover occurs in the 8 node cluster, a deadlock is seen on the JBoss instances that host the MDBs.
> {code}
> Found one Java-level deadlock:
> =============================
> "Thread-177":
> waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
> which is held by "Thread-130"
> "Thread-130":
> waiting to lock monitor 0x08aea1a4 (object 0x81dde148, a java.lang.Object),
> which is held by "Timer-18"
> "Timer-18":
> waiting to lock monitor 0x4c561e18 (object 0x7c3dfdb0, a java.lang.Object),
> which is held by "Thread-130"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-177":
> at org.jboss.remoting.Client.removeConnectionListener(Client.java:599)
> - waiting to lock <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:565)
> - locked <0x7f589740> (a org.jboss.jms.client.remoting.JMSRemotingConnection)
> at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
> at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownConnection(JmsActivation.java:635)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:376)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:275)
> at org.jboss.resource.adapter.jms.inflow.JmsActivation.onException(JmsActivation.java:312)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)
> - locked <0x7f320410> (a java.lang.Object)
> - locked <0x7f5899a0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
> at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
> "Thread-130":
> at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
> - waiting to lock <0x81dde148> (a java.lang.Object)
> at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
> - locked <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.remoting.Client.connect(Client.java:1918)
> at org.jboss.remoting.Client.connect(Client.java:737)
> at org.jboss.jms.client.remoting.JMSRemotingConnection$1.run(JMSRemotingConnection.java:374)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:368)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:175)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_25018031.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_25018031.java)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:62)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:84)
> - locked <0x813598d0> (a org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener)
> at org.jboss.remoting.ConnectionValidator$3.run(ConnectionValidator.java:524)
> "Timer-18":
> at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
> - waiting to lock <0x7c3dfdb0> (a java.lang.Object)
> at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
> at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
> - locked <0x81dde148> (a java.lang.Object)
> at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> Found 1 deadlock.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3851) WildFly 8.1 + JAX-WS and attaching Spring dependency
by Dmitriy Shishmakov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3851?page=com.atlassian.jira.plugin.... ]
Dmitriy Shishmakov commented on WFLY-3851:
------------------------------------------
Yes, the issue depends on "asm.jar" library. "Cglib" library was changed to "cglib-nodep" library that already include "asm".
Project on github has changed.
What should I do in situation with original "cglib.jar"?
> WildFly 8.1 + JAX-WS and attaching Spring dependency
> ----------------------------------------------------
>
> Key: WFLY-3851
> URL: https://issues.jboss.org/browse/WFLY-3851
> Project: WildFly
> Issue Type: Task
> Components: EE
> Affects Versions: 8.1.0.Final
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
> WildFly 8.1.0 Final
> Spring 3.1.1
> JBossWS 2.2
> Windows 7
> Reporter: Dmitriy Shishmakov
> Assignee: Alessio Soldano
> Attachments: asm.png, server.log
>
>
> I was made a prototype project 'maven-ws-prototype' for showing a trouble WildFly 8.1 with Spring 3.1.
> This maven EAR project is contains 2 WebServices. I attached Spring dependencies In 'war' submodule. I don't use them in java classes.
> Project has been successfully deployed into JBoss 7.1.1 but didn't deployed in WildFly 8.1.
> GitHub: https://github.com/DmitriySh/maven-ws-prototype
> If everything ok links might be invoke.
> http://localhost:8080/jboss7-war/CalculatorImpl?wsdl
> http://localhost:8080/jboss7-ejb/RandomGeneratorImpl/RandomGeneratorServi...
> Stack trace:
> ---------------
> 2014-09-12 17:50:30,502 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-1) Creating Service {http://service.ejb.jaxws.company.com}RandomGeneratorImpl from class com.company.jaxws.ejb.service.RandomGenerator
> 2014-09-12 17:50:30,502 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-2) Creating Service {http://service.servlet.jaxws.company.com}CalculatorImpl from class com.company.jaxws.servlet.service.Calculator
> 2014-09-12 17:50:30,556 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment "jboss7-war.war" of deployment "jboss7-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)
> at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:137)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:69)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 5 more
> Caused by: java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy30.visitLabel(Unknown Source)
> at org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:213)
> at org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683)
> at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:653)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:484)
> at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:704)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550)
> at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265)
> at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215)
> at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
> at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)
> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:456)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:334)
> ... 13 more
> Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)
> at java.lang.Class.getMethod(Class.java:1665) [rt.jar:1.7.0_60]
> at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85)
> ... 28 more
> 2014-09-12 17:50:30,877 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-1) Setting the server's publish address to be http://localhost:8080/jboss7-ejb/RandomGeneratorImpl/RandomGeneratorService
> 2014-09-12 17:50:30,942 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-1) JBWS024074: WSDL published to: file:/C:/work/wildfly-8.1.0.Final/standalone/data/wsdl/jboss7-ear.ear/jboss7-ejb.jar/RandomGeneratorImpl.wsdl
> 2014-09-12 17:50:30,981 INFO [org.jboss.as.webservices] (MSC service thread 1-2) JBAS015539: Starting service jboss.ws.endpoint."jboss7-ear.ear"."jboss7-ejb.jar".RandomGeneratorService
> 2014-09-12 17:50:30,991 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jboss7-ear.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"jboss7-ear.ear\".\"jboss7-war.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"jboss7-ear.ear\".\"jboss7-war.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment \"jboss7-war.war\" of deployment \"jboss7-ear.ear\"
> Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException
> Caused by: java.lang.reflect.UndeclaredThrowableException
> Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"jboss7-ear.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"jboss7-ear.ear\".\"jboss7-war.war\".deploymentCompleteService]",
> "jboss.deployment.unit.\"jboss7-ear.ear\".WeldStartService is missing [jboss.deployment.subunit.\"jboss7-ear.ear\".\"jboss7-war.war\".jndiDependencyService]"
> ]
> }
> 2014-09-12 17:50:31,035 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "jboss7-ear.ear" (runtime-name : "jboss7-ear.ear")
> 2014-09-12 17:50:31,037 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."jboss7-ear.ear".deploymentCompleteService]
> service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."jboss7-ear.ear".WeldStartService]
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jboss7-ear.ear"."jboss7-war.war".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment "jboss7-war.war" of deployment "jboss7-ear.ear"
> 2014-09-12 17:50:38,557 ERROR [stderr] (XNIO-1 task-5) java.lang.IllegalArgumentException: UT000024: An invalidly formatted nonce has been received.
> 2014-09-12 17:50:38,558 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SimpleNonceManager.verifyUnknownNonce(SimpleNonceManager.java:375)
> 2014-09-12 17:50:38,559 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SimpleNonceManager.validateNonce(SimpleNonceManager.java:258)
> 2014-09-12 17:50:38,559 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.DigestAuthenticationMechanism.validateNonceUse(DigestAuthenticationMechanism.java:331)
> 2014-09-12 17:50:38,560 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:276)
> 2014-09-12 17:50:38,561 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149)
> 2014-09-12 17:50:38,561 ERROR [stderr] (XNIO-1 task-5) at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57)
> 2014-09-12 17:50:38,562 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
> 2014-09-12 17:50:38,562 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
> 2014-09-12 17:50:38,563 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
> 2014-09-12 17:50:38,563 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
> 2014-09-12 17:50:38,563 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
> 2014-09-12 17:50:38,564 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
> 2014-09-12 17:50:38,564 ERROR [stderr] (XNIO-1 task-5) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> 2014-09-12 17:50:38,565 ERROR [stderr] (XNIO-1 task-5) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> 2014-09-12 17:50:38,565 ERROR [stderr] (XNIO-1 task-5) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 2014-09-12 17:50:38,565 ERROR [stderr] (XNIO-1 task-5) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 2014-09-12 17:50:38,566 ERROR [stderr] (XNIO-1 task-5) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 2014-09-12 17:50:38,566 ERROR [stderr] (XNIO-1 task-5) at java.lang.Thread.run(Thread.java:745)
--
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/15/14 7:58 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* -CreditMap- (only used for measuring block times)
* -FlowControl-
* -Locking-
* -MERGE2-
* -RELAY2- (no change; only used for stats)
* -StatsCollector-
* -RATE_LIMITER-
* -PERF-
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* -CreditMap- (only used for measuring block times)
* -FlowControl-
* Locking
* -MERGE2-
* -RELAY2- (no change; only used for stats)
* -StatsCollector-
* -RATE_LIMITER-
* -PERF-
> 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] (JBRULES-3358) Fix reload of KnowledgeAgent resources: CSV, XLS, BPMN, DRF, PKG
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3358?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on JBRULES-3358:
--------------------------------------------------
Geoffrey De Smet <gdesmet(a)redhat.com> changed the Status of [bug 732085|https://bugzilla.redhat.com/show_bug.cgi?id=732085] from VERIFIED to CLOSED
> Fix reload of KnowledgeAgent resources: CSV, XLS, BPMN, DRF, PKG
> ----------------------------------------------------------------
>
> Key: JBRULES-3358
> URL: https://issues.jboss.org/browse/JBRULES-3358
> Project: JBRULES
> Issue Type: Bug
> Components: drools-compiler, drools-core, drools-decisiontables
> Affects Versions: 5.3.1.Final, 5.4.0.Beta1
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 5.3.2.Final, 5.4.0.Beta2
>
>
> Placeholder JIRA for several BZ issues as linked.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-3852?page=com.atlassian.jira.plugin.... ]
Tibor Digana commented on WFLY-3852:
------------------------------------
Yes please make a reseach in the expert group.
Both annotations @Lock and @AccessTimeout were introduced in EJB 3.1, so none of them should have higher priority.
IMHO the @AT only changes the management of thread resources. It would not change the behavior of locks.
This means that @Lock(WRITE) will hold another concurrent Thread,
but @AT + @Lock(WRITE) does not block the concurrent thread and therefore such thread comes back to the thread-pool and can be reused by the thread-pool to execute other async tasks.
That's very important because without @AT the j2ee wouldn't have a way to prevent from deadlock.
Imaging what would happen if thread-pool size is too small and all threads are waiting for eachother - deadlock.
This happened to me with asynchronous REST client. Therefore the blocked threads can be reused in EJB 3.1, and the @AT would do it for me.
> EJB @Schedule interleaves timer calls with @AccessTimeout(0)
> ------------------------------------------------------------
>
> Key: WFLY-3852
> URL: https://issues.jboss.org/browse/WFLY-3852
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: Win 7 x64 / i7
> Reporter: Tibor Digana
> Assignee: David Lloyd
> Priority: Critical
>
> Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker skipping scheduler on concurrent Thread.
> Actual:
> The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls interleave concurrently.
> Expected:
> The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter which LockType is used.
> According to the Javadoc
> "A value of 0 means concurrent access is not permitted."
> In other words the timer should give it up on concurrent Thread.
> The timer should not wait for read/write lock due to the value in the annotation is not -1.
> In the internal implementation of TomEE server the timer skips scheduling if Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not matter.
> Don't be confused with WFLY-3430.
> I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with whatever LockType. If this annotation is not used then the next call should be concurrent / blocked depending on READ / WRITE LockType, respectively.
> My code:
> @Startup
> @Singleton
> @Lock(READ)
> public class MyTimer {
> @Schedule(minute = "*", hour = "*", persistent = false, info = "My Timer")
> @AccessTimeout(0)
> public void updateByMinutes() {}
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1882) Possible NullPointerException in JDBC_PING
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1882?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1882:
---------------------------
Fix Version/s: 3.5.1
3.6
Description:
JGroups version: 3.5.0 final
{noformat}
Caused by: java.lang.NullPointerException
at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:225)
at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:192)
at org.jgroups.protocols.JDBC_PING.findMembers(Katalis.java:128)
at org.jgroups.protocols.Discovery.findMembers(Katalis.java:226)
at org.jgroups.protocols.Discovery.down(Katalis.java:366)
at org.jgroups.protocols.JDBC_PING.down(Katalis.java:124)
at org.jgroups.protocols.MERGE2.down(Katalis.java:222)
at org.jgroups.protocols.FD_SOCK.down(Katalis.java:356)
at org.jgroups.protocols.FD_ALL.down(Katalis.java:233)
at org.jgroups.protocols.VERIFY_SUSPECT.down(Katalis.java:92)
at org.jgroups.protocols.pbcast.NAKACK2.down(Katalis.java:551)
at org.jgroups.protocols.UNICAST2.down(Katalis.java:584)
at org.jgroups.protocols.pbcast.STABLE.down(Katalis.java:347)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(Katalis.java:76)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(Katalis.java:41)
at org.jgroups.protocols.pbcast.GMS.down(Katalis.java:1084)
at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
at org.jgroups.protocols.FRAG2.down(Katalis.java:136)
at org.jgroups.protocols.RSVP.down(Katalis.java:145)
at org.jgroups.stack.ProtocolStack.down(Katalis.java:1039)
at org.jgroups.JChannel.down(Katalis.java:785)
at org.jgroups.JChannel._connect(Katalis.java:558)
... 40 more
{noformat}
I suspect that data is null. The code in line 225 is
{code}
if(local_addr != null && !local_addr.equals(data.getAddress()))
addDiscoveryResponseToCaches(data.getAddress(), data.getLogicalName(), data.getPhysicalAddr());
{code}
was:
JGroups version: 3.5.0 final
{noformat}
Caused by: java.lang.NullPointerException
at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:225)
at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:192)
at org.jgroups.protocols.JDBC_PING.findMembers(Katalis.java:128)
at org.jgroups.protocols.Discovery.findMembers(Katalis.java:226)
at org.jgroups.protocols.Discovery.down(Katalis.java:366)
at org.jgroups.protocols.JDBC_PING.down(Katalis.java:124)
at org.jgroups.protocols.MERGE2.down(Katalis.java:222)
at org.jgroups.protocols.FD_SOCK.down(Katalis.java:356)
at org.jgroups.protocols.FD_ALL.down(Katalis.java:233)
at org.jgroups.protocols.VERIFY_SUSPECT.down(Katalis.java:92)
at org.jgroups.protocols.pbcast.NAKACK2.down(Katalis.java:551)
at org.jgroups.protocols.UNICAST2.down(Katalis.java:584)
at org.jgroups.protocols.pbcast.STABLE.down(Katalis.java:347)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(Katalis.java:76)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(Katalis.java:41)
at org.jgroups.protocols.pbcast.GMS.down(Katalis.java:1084)
at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
at org.jgroups.protocols.FRAG2.down(Katalis.java:136)
at org.jgroups.protocols.RSVP.down(Katalis.java:145)
at org.jgroups.stack.ProtocolStack.down(Katalis.java:1039)
at org.jgroups.JChannel.down(Katalis.java:785)
at org.jgroups.JChannel._connect(Katalis.java:558)
... 40 more
{noformat}
I suspect that data is null. The code in line 225 is
{code}
if(local_addr != null && !local_addr.equals(data.getAddress()))
addDiscoveryResponseToCaches(data.getAddress(), data.getLogicalName(), data.getPhysicalAddr());
{code}
> Possible NullPointerException in JDBC_PING
> ------------------------------------------
>
> Key: JGRP-1882
> URL: https://issues.jboss.org/browse/JGRP-1882
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows Server 2012
> Reporter: Thomas Santosa
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> JGroups version: 3.5.0 final
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:225)
> at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:192)
> at org.jgroups.protocols.JDBC_PING.findMembers(Katalis.java:128)
> at org.jgroups.protocols.Discovery.findMembers(Katalis.java:226)
> at org.jgroups.protocols.Discovery.down(Katalis.java:366)
> at org.jgroups.protocols.JDBC_PING.down(Katalis.java:124)
> at org.jgroups.protocols.MERGE2.down(Katalis.java:222)
> at org.jgroups.protocols.FD_SOCK.down(Katalis.java:356)
> at org.jgroups.protocols.FD_ALL.down(Katalis.java:233)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(Katalis.java:92)
> at org.jgroups.protocols.pbcast.NAKACK2.down(Katalis.java:551)
> at org.jgroups.protocols.UNICAST2.down(Katalis.java:584)
> at org.jgroups.protocols.pbcast.STABLE.down(Katalis.java:347)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(Katalis.java:76)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(Katalis.java:41)
> at org.jgroups.protocols.pbcast.GMS.down(Katalis.java:1084)
> at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
> at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
> at org.jgroups.protocols.FRAG2.down(Katalis.java:136)
> at org.jgroups.protocols.RSVP.down(Katalis.java:145)
> at org.jgroups.stack.ProtocolStack.down(Katalis.java:1039)
> at org.jgroups.JChannel.down(Katalis.java:785)
> at org.jgroups.JChannel._connect(Katalis.java:558)
> ... 40 more
> {noformat}
> I suspect that data is null. The code in line 225 is
> {code}
> if(local_addr != null && !local_addr.equals(data.getAddress()))
> addDiscoveryResponseToCaches(data.getAddress(), data.getLogicalName(), data.getPhysicalAddr());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years