[JBoss JIRA] (WFLY-5304) NullPointerException during server graceful shutdown after EJBClient invocation arrived
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5304?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-5304 at 3/4/16 11:30 AM:
--------------------------------------------------------------------
Upon reflection, I think I wasn't looking at this issue correctly, focussing too much on one specific issue: what to do when the server is shutting down and we have method invocations still arriving. I think there is a larger issue to deal with.
VersionOneProtocolChannelReceiver handles four classes of incoming EJB related messages:
- method invocations
- session creation requests
- async invocation cancellation requests
- EJB client txn related requests (prepare, commit, rollback, forget, before completion)
This issue is this: how do we respond to incoming requests of all of these types:
- when the server is in process of suspending (in pre-suspend phase)
- when the server has suspended
The first step was to introduce the EjbSuspendInterceptor in the invocation interceptor chain. This causes a NoSuchEJBException to be returned for all invocations arriving after pre-suspend has started. Such a message response tells the EJB client to look for another server to make the invocation on. This is per-invocation request.
The second step was to introduce a ServerActivity interface for VersionOne. The purpose of this was to allow the server to tell all connected clients when it was suspending (i.e. all EJB deployments on the server are no longer available, go look for another one) and when it was resuming (i.e. all EJB deployments on the server are now again available). The idea was to inform clients so that they would stop directing messages to the suspended server.
The problems:
- even with the ServerActivity added, requests of all four classes can get sent from the client to the server and start processing, even when the server is actually suspended, due to race condition
- we don't seem to have a policy in place for what to send back to the client in the case of such requests (other than invocations) when the server is suspended
One possible solution here is to expand the function of the ServerActivity callback in VersionOne to handle more than notification to clients that the server is in pre-suspend or suspended or resumed. For example, it could provide local awareness of when the server was in presuspend, suspend or resume and use that information to handle arriving invocations. In particular, we need to decide what to do in each of these cases:
MethodInvocationMessageHandler (handles invocation processing):
* pre-suspend: currently, send NoSuchEJBException sent to client
* suspended: currently, send NoSuchEJBEXception to client via EjbSuspendInterceptor but if the server follows suspend by a shutdown this potentially results in the NPE issue described here
* resumed: process as normal
InvocationCancellationMessageHandler (handles cancelling asynchronous invocation task):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
SessionOpenRequestHandler (handles creating stateful session and returning id):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
TransactionRequestHandler (handles transaction requests prepare, commit, rollback, forget, before completion):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
was (Author: rachmato):
Upon reflection, I think I wasn't looking at this issue correctly, focussing too much on one specific issue: what to do when the server is shutting down and we have method invocations still arriving. I think there is a larger issue to deal with.
VersionOneProtocolChannelReceiver handles four classes of incoming EJB related messages:
- method invocations
- session creation requests
- async invocation cancellation requests
- EJB client txn related requests (prepare, commit, rollback, forget, before completion)
This issue is this: how do we respond to incoming requests of all of these types:
- when the server is in process of suspending (in pre-suspend phase)
- when the server has suspended
The first step was to introduce the EjbSuspendInterceptor in the invocation interceptor chain. This causes a NoSuchEJBException to be returned for all invocations arriving after pre-suspend has started. Such a message response tells the EJB client to look for another server to make the invocation on. This is per-invocation request.
The second step was to introduce a ServerActivity interface for VersionOne. The purpose of this was to allow the server to tell all connected clients when it was suspending (i.e. all EJB deployments on the server are no longer available, go look for another one) and when it was resuming (i.e. all EJB deployments on the server are now again available). The idea was to inform clients so that they would stop directing messages to the suspended server.
The problems:
- even with the ServerActivity added, requests of all four classes can get sent from the client to the server, even when the server is actually suspended, due to race condition
- we don't seem to have a policy in place for what to send back to the client in the case of such requests (other than invocations) when the server is suspended
One possible solution here is to expand the function of the ServerActivity callback in VersionOne to handle more than notification to clients that the server is in pre-suspend or suspended or resumed. For example, it could provide local awareness of when the server was in presuspend, suspend or resume and use that information to handle arriving invocations. In particular, we need to decide what to do in each of these cases:
MethodInvocationMessageHandler (handles invocation processing):
* pre-suspend: currently, send NoSuchEJBException sent to client
* suspended: currently, send NoSuchEJBEXception to client via EjbSuspendInterceptor but if the server follows suspend by a shutdown this potentially results in the NPE issue described here
* resumed: process as normal
InvocationCancellationMessageHandler (handles cancelling asynchronous invocation task):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
SessionOpenRequestHandler (handles creating stateful session and returning id):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
TransactionRequestHandler (handles transaction requests prepare, commit, rollback, forget, before completion):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
> NullPointerException during server graceful shutdown after EJBClient invocation arrived
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5304
> URL: https://issues.jboss.org/browse/WFLY-5304
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3@45c60b2c: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[0m09:02:25,104 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds.
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=...
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5304) NullPointerException during server graceful shutdown after EJBClient invocation arrived
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5304?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-5304 at 3/4/16 10:55 AM:
--------------------------------------------------------------------
Upon reflection, I think I wasn't looking at this issue correctly, focussing too much on one specific issue: what to do when the server is shutting down and we have method invocations still arriving. I think there is a larger issue to deal with.
VersionOneProtocolChannelReceiver handles four classes of incoming EJB related messages:
- method invocations
- session creation requests
- async invocation cancellation requests
- EJB client txn related requests (prepare, commit, rollback, forget, before completion)
This issue is this: how do we respond to incoming requests of all of these types:
- when the server is in process of suspending (in pre-suspend phase)
- when the server has suspended
The first step was to introduce the EjbSuspendInterceptor in the invocation interceptor chain. This causes a NoSuchEJBException to be returned for all invocations arriving after pre-suspend has started. Such a message response tells the EJB client to look for another server to make the invocation on. This is per-invocation request.
The second step was to introduce a ServerActivity interface for VersionOne. The purpose of this was to allow the server to tell all connected clients when it was suspending (i.e. all EJB deployments on the server are no longer available, go look for another one) and when it was resuming (i.e. all EJB deployments on the server are now again available). The idea was to inform clients so that they would stop directing messages to the suspended server.
The problems:
- even with the ServerActivity added, requests of all four classes can get sent from the client to the server, even when the server is actually suspended, due to race condition
- we don't seem to have a policy in place for what to send back to the client in the case of such requests (other than invocations) when the server is suspended
One possible solution here is to expand the function of the ServerActivity callback in VersionOne to handle more than notification to clients that the server is in pre-suspend or suspended or resumed. For example, it could provide local awareness of when the server was in presuspend, suspend or resume and use that information to handle arriving invocations. In particular, we need to decide what to do in each of these cases:
MethodInvocationMessageHandler (handles invocation processing):
* pre-suspend: currently, send NoSuchEJBException sent to client
* suspended: currently, send NoSuchEJBEXception to client via EjbSuspendInterceptor but if the server follows suspend by a shutdown this potentially results in the NPE issue described here
* resumed: process as normal
InvocationCancellationMessageHandler (handles cancelling asynchronous invocation task):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
SessionOpenRequestHandler (handles creating stateful session and returning id):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
TransactionRequestHandler (handles transaction requests prepare, commit, rollback, forget, before completion):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
was (Author: rachmato):
Upon reflection, I think I wasn't looking at this issue correctly, focussing too much on one specific issue: what to do when the server is shutting down and we have method invocations still arriving. I think there is a larger issue to deal with.
VersionOneProtocolChannelReceiver handles four classes of incoming EJB related messages:
- method invocations
- session creation requests
- async invocation cancellation requests
- EJB client txn related requests (prepare, commit, rollback, forget, before completion)
This issue is this: how do we respond to incoming requests lf all of these types:
- when the server is in process of suspending (in pre-suspend phase)
- when the server has suspended
The first step was to introduce the EjbSuspendInterceptor in the invocation interceptor chain. This causes a NoSuchEJBException to be returned for all invocations arriving after pre-suspend has started. Such a message response tells the EJB client to look for another server to make the invocation on. This is per-invocation request.
The second step was to introduce a ServerActivity interface for VersionOne. The purpose of this was to allow the server to tell all connected clients when it was suspending (i.e. all EJB deployments on the server are no longer available, go look for another one) and when it was resuming (i.e. all EJB deployments on the server are now again available). The idea was to inform clients so that they would stop directing messages to the suspended server.
The problems:
- even with the ServerActivity added, requests of all four classes can get sent from the client to the server, even when the server is actually suspended, due to race condition
- we don't seem to have a policy in place for what to send back to the client in the case of such requests (other than invocations) when the server is suspended
One possible solution here is to expand the function of the ServerActivity callback in VersionOne to handle more than notification to clients that the server is in pre-suspend or suspended or resumed. For example, it could provide local awareness of when the server was in presuspend, suspend or resume and use that information to handle arriving invocations. In particular, we need to decide what to do in each of these cases:
MethodInvocationMessageHandler (handles invocation processing):
* pre-suspend: currently, send NoSuchEJBException sent to client
* suspended: currently, send NoSuchEJBEXception to client via EjbSuspendInterceptor but if the server follows suspend by a shutdown this potentially results in the NPE issue described here
* resumed: process as normal
InvocationCancellationMessageHandler (handles cancelling asynchronous invocation task):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
SessionOpenRequestHandler (handles creating stateful session and returning id):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
TransactionRequestHandler (handles transaction requests prepare, commit, rollback, forget, before completion):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
> NullPointerException during server graceful shutdown after EJBClient invocation arrived
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5304
> URL: https://issues.jboss.org/browse/WFLY-5304
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3@45c60b2c: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[0m09:02:25,104 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds.
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=...
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5304) NullPointerException during server graceful shutdown after EJBClient invocation arrived
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5304?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5304:
-------------------------------------------
Upon reflection, I think I wasn't looking at this issue correctly, focussing too much on one specific issue: what to do when the server is shutting down and we have method invocations still arriving. I think there is a larger issue to deal with.
VersionOneProtocolChannelReceiver handles four classes of incoming EJB related messages:
- method invocations
- session creation requests
- async invocation cancellation requests
- EJB client txn related requests (prepare, commit, rollback, forget, before completion)
This issue is this: how do we respond to incoming requests lf all of these types:
- when the server is in process of suspending (in pre-suspend phase)
- when the server has suspended
The first step was to introduce the EjbSuspendInterceptor in the invocation interceptor chain. This causes a NoSuchEJBException to be returned for all invocations arriving after pre-suspend has started. Such a message response tells the EJB client to look for another server to make the invocation on. This is per-invocation request.
The second step was to introduce a ServerActivity interface for VersionOne. The purpose of this was to allow the server to tell all connected clients when it was suspending (i.e. all EJB deployments on the server are no longer available, go look for another one) and when it was resuming (i.e. all EJB deployments on the server are now again available). The idea was to inform clients so that they would stop directing messages to the suspended server.
The problems:
- even with the ServerActivity added, requests of all four classes can get sent from the client to the server, even when the server is actually suspended, due to race condition
- we don't seem to have a policy in place for what to send back to the client in the case of such requests (other than invocations) when the server is suspended
One possible solution here is to expand the function of the ServerActivity callback in VersionOne to handle more than notification to clients that the server is in pre-suspend or suspended or resumed. For example, it could provide local awareness of when the server was in presuspend, suspend or resume and use that information to handle arriving invocations. In particular, we need to decide what to do in each of these cases:
MethodInvocationMessageHandler (handles invocation processing):
* pre-suspend: currently, send NoSuchEJBException sent to client
* suspended: currently, send NoSuchEJBEXception to client via EjbSuspendInterceptor but if the server follows suspend by a shutdown this potentially results in the NPE issue described here
* resumed: process as normal
InvocationCancellationMessageHandler (handles cancelling asynchronous invocation task):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
SessionOpenRequestHandler (handles creating stateful session and returning id):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
TransactionRequestHandler (handles transaction requests prepare, commit, rollback, forget, before completion):
* pre-suspend: TBD
* suspended: TBD
* resumed: TBD
> NullPointerException during server graceful shutdown after EJBClient invocation arrived
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5304
> URL: https://issues.jboss.org/browse/WFLY-5304
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3@45c60b2c: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[0m09:02:25,104 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds.
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=...
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5304) NullPointerException during server graceful shutdown after EJBClient invocation arrived
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5304?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5304:
-------------------------------------------
There was some discussion last night on HipChat about this issue, concerning the following points:
- why are we not using ServerActivity callbacks to deal with this instead of trying to determine when the server is shutting down
- the server shutdown can be determined by org.jboss.msc.service.ServiceContainer#isShutdown
> NullPointerException during server graceful shutdown after EJBClient invocation arrived
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5304
> URL: https://issues.jboss.org/browse/WFLY-5304
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3@45c60b2c: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[0m09:02:25,104 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds.
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=...
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6320) JCETestCase fails with security manager enabled on OracleJDK
by Jan Tymel (JIRA)
Jan Tymel created WFLY-6320:
-------------------------------
Summary: JCETestCase fails with security manager enabled on OracleJDK
Key: WFLY-6320
URL: https://issues.jboss.org/browse/WFLY-6320
Project: WildFly
Issue Type: Bug
Components: Test Suite
Environment: OracleJDK (tested with versions 1.8.0_71 and 1.8.0_74)
Reporter: Jan Tymel
*org.jboss.as.test.integration.deployment.jcedeployment.JCETestCase#testJCE*
Steps to reproduce:
{{./integration-tests.sh -Dts.basic -Dts.noSmoke -DtestLogToFile=false -Dsecurity.manager -Dtest=org.jboss.as.test.integration.deployment.jcedeployment.JCETestCase#testJCE}}
Fails with:
{code}
ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /test/controller: javax.servlet.ServletException: Cannot install the certificate to the validator.
at org.jboss.as.test.integration.deployment.jcedeployment.ControllerServlet.init(ControllerServlet.java:80)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:170)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "../jcetest.keystore" "read")" in code source "(vfs:/content/jcetest.ear/test.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
at java.io.FileInputStream.<init>(FileInputStream.java:127)
at java.io.FileInputStream.<init>(FileInputStream.java:93)
at org.jboss.as.test.integration.deployment.jcedeployment.ControllerServlet.init(ControllerServlet.java:65)
... 34 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1428) log-file.stream attribute is of type LONG but contains a string
by Harald Pehl (JIRA)
Harald Pehl created WFCORE-1428:
-----------------------------------
Summary: log-file.stream attribute is of type LONG but contains a string
Key: WFCORE-1428
URL: https://issues.jboss.org/browse/WFCORE-1428
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 2.1.0.CR1
Reporter: Harald Pehl
Assignee: James Perkins
The {{stream}} attribute of the {{log-file}} resource is of type LONG, but contains a UUID (string). This leads to an error in the console where I rely on proper attribute data types.
{{/subsystem=logging/log-file=*:read-resource-description}}
{{/subsystem=logging/log-file=*:read-resource(include-runtime=true)}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6294) mod_cluster session drain wait does not end
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-6294:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1314792
Bugzilla Update: Perform
> mod_cluster session drain wait does not end
> -------------------------------------------
>
> Key: WFLY-6294
> URL: https://issues.jboss.org/browse/WFLY-6294
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Radoslav Husar
>
> The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
> {code}
> while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
> ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
> listener.wait(noTimeout ? 0 : timeout);
> current = System.currentTimeMillis();
> timeout = end - current;
> remainingSessions = context.getActiveSessionCount();
> }
> {code}
> Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1079) Kie navigator cannot show organizational units content
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1079?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1079:
--------------------------------
Priority: Blocker (was: Critical)
> Kie navigator cannot show organizational units content
> ------------------------------------------------------
>
> Key: DROOLS-1079
> URL: https://issues.jboss.org/browse/DROOLS-1079
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: JBoss Developer Studio 9.1.0.Beta2
> Drools plugin 6.4.0.201601201107
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Priority: Blocker
> Labels: reported-by-qe
>
> It is not possible to open organizational units and display associated repositories. Also when you create a new repository in org unit, it is not displayed in kie navigator but in business central app it is correctly created.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5304) NullPointerException during server graceful shutdown after EJBClient invocation arrived
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5304?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-5304:
--------------------------------------
Last time we had seen this issue was during ER4 testing.
> NullPointerException during server graceful shutdown after EJBClient invocation arrived
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5304
> URL: https://issues.jboss.org/browse/WFLY-5304
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3@45c60b2c: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[0m09:02:25,104 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds.
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=...
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month