[JBoss JIRA] (WFLY-10340) Enable OpenJPA integration tests for Java 10
by Scott Marlow (JIRA)
Scott Marlow created WFLY-10340:
-----------------------------------
Summary: Enable OpenJPA integration tests for Java 10
Key: WFLY-10340
URL: https://issues.jboss.org/browse/WFLY-10340
Project: WildFly
Issue Type: Enhancement
Components: JPA / Hibernate
Reporter: Scott Marlow
Assignee: Scott Marlow
Priority: Minor
Disable OpenJPA testing due to WFLY-10177 which reports test failures only on JDK10. When OpenJPA supports Java 10, re-enable OpenJPA testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3002) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3002?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3002:
----------------------------------------
Assignee: (was: Brian Stansberry)
> (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3002
> URL: https://issues.jboss.org/browse/WFCORE-3002
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Reporter: Josef Cacek
>
> The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
> *Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
> Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
> My first try was to use ModelControllerClient configuration to set SSL context:
> {code:java}
> new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
> .setProtocol("remote");
> {code}
> Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
> Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
> {code:java}
> AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
> {code}
> The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
> {quote}
> In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
> {quote}
> Based on the comment I've used "remote+tls" protocol on the client:
> {code:java}
> ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
> {code}
> but in this case the connection fails even if the server has the sslContext configured:
> {code:xml}
> <management-interfaces>
> <native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
> <socket-binding native="testbinding"/>
> </native-interface>
> ...
> </management-interfaces>
> {code}
> The failure:
> {noformat}
> java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ... [cropped]
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> ... 144 more
> Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> {noformat}
> Am I missing some piece of configuration here?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2957) read-resource without include-runtime shows runtime-only resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2957?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2957:
----------------------------------------
Assignee: (was: Brian Stansberry)
> read-resource without include-runtime shows runtime-only resources
> ------------------------------------------------------------------
>
> Key: WFCORE-2957
> URL: https://issues.jboss.org/browse/WFCORE-2957
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Michal Petrov
>
> read-resource without explicitly set include-runtime will show runtime-only resources
> {code}
> /extension=org.jboss.as.weld:read-resource()
> {
> "outcome" => "success",
> "result" => {
> "module" => "org.jboss.as.weld",
> "subsystem" => {"weld" => undefined}
> }
> }
> {code}
> however adding "recursive" will not show the resource at all:
> {code}
> /extension=org.jboss.as.weld:read-resource(recursive)
> {
> "outcome" => "success",
> "result" => {
> "module" => "org.jboss.as.weld",
> "subsystem" => undefined
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3298) EnumValidator should avoid trying to modify protected nodes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3298?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3298:
----------------------------------------
Assignee: (was: Brian Stansberry)
> EnumValidator should avoid trying to modify protected nodes
> -----------------------------------------------------------
>
> Key: WFCORE-3298
> URL: https://issues.jboss.org/browse/WFCORE-3298
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
>
> EnumValidator is trying to "correct" inputs by converting the input node to the official name of the enum. This results a caught and discarded UnsupportedOperationException if the node is protected. Catching an exception is a poor way to do this.
> Simply not doing the write if the input is the same as the official value is one way to mitigate this, but better is to wait for DMR-37 and just check if the node is protected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3634) ActiveOperationImpl should remove the operation from the handler before signalling the result handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3634?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3634:
----------------------------------------
Assignee: (was: Brian Stansberry)
> ActiveOperationImpl should remove the operation from the handler before signalling the result handler
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3634
> URL: https://issues.jboss.org/browse/WFCORE-3634
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Priority: Optional
>
> Caution: this is a theoretical solution to a problem.
> I'm seeing a fairly frequent problem with the use of org.wildfly.core.testrunner.Server.reload() where the reload is proceeding but the server log shows the following, followed by various undesirable things and a test failure of one sort or another:
> {code}
> &#27;[0m&#27;[0m07:50:27,581 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 1,5,management-handler-thread]
> {code}
> I believe the issue is that Server.executeReload is closing the client in a finally block immediately after reading the response to reload. But the server sends the response to reload *early* so on the server side the op is still in progress. The client-side close of the client is resulting in cancellation of that still in-progress op.
> But why is the close of the client causing cancellation? The client has received the response; why is it still tracking the operation? My theory is that the ResultHandler created by ActiveOperationImpl is publishing the result (or failure) before it removes the active operation from tracking in a finally block. Doing this in the opposite order would mean the active op would be cleared before the result is published.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3628) Ensure services installed by HostControllerService and ApplicationServerService are tracked by the ContainerStateMonitor
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3628?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3628:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Ensure services installed by HostControllerService and ApplicationServerService are tracked by the ContainerStateMonitor
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3628
> URL: https://issues.jboss.org/browse/WFCORE-3628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> WFCORE-3624 is a specific example of a more general problem -- services that may be recorded as dependencies of services installed by management ops are not tracked by the ContainerStateMonitor. This makes it possible to get problems like WFCORE-3624.
> In practice WFCORE-3624 is fairly unique, as the problem service was ON_DEMAND. Also, most services installed by HostControllerService and ApplicationServerService are themselves dependencies of DomainModelControllerService and ServerService (which provide the ModelController) so if they are not started no management ops can proceed. But the code would be more robust if the way these were installed involved logic that led to them being tracked by the StabilityMonitor used by ContainerStateMonitor. Doing this would help ensure that future services like this don't fall into a crack the way ExternalManagementRequestExecutor did.
> Note -- I don't think DomainModelControllerService and ServerService themselves should be monitored. Not HostControllerService and ApplicationServerService either.
> Here's some analysis I did when trying to figure out WFCORE-3624:
> HostControllerService
> ---------------------
> ProcessControllerConnectionService -- DMCS depends
> HostControllerExecutorService -- DMCS depends
> HostPathManagerService - DMCS depends
> HostControllerScheduledExecutorService -- no dep
> Value<ProductConfig> -- no dep
> ExternalManagementRequestExecutor -- no dep
> ApplicationServerService
> ------------------------
> ContentRepositoryImpl or RemoteFileRepositoryService -- SS depends
> ContentCleanerService -- no dep
> ServerDeploymentRepositoryImpl -- SS depends
> ServiceModuleLoader -- SS depends
> ExternalModuleService -- SS depends
> ServerPathManagerService -- SS depends
> ServerEnvironmentService -- no dep
> Value<ProductConfig> -- no dep
> ServerExecutorService -- SS dep *if* executor is configured
> ServerScheduledExecutorService -- no dep
> ExternalManagementRequestExecutor -- no dep
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3628) Ensure services installed by HostControllerService and ApplicationServerService are tracked by the ContainerStateMonitor
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3628?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3628:
-------------------------------------
Labels: domain-mode (was: )
> Ensure services installed by HostControllerService and ApplicationServerService are tracked by the ContainerStateMonitor
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3628
> URL: https://issues.jboss.org/browse/WFCORE-3628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> WFCORE-3624 is a specific example of a more general problem -- services that may be recorded as dependencies of services installed by management ops are not tracked by the ContainerStateMonitor. This makes it possible to get problems like WFCORE-3624.
> In practice WFCORE-3624 is fairly unique, as the problem service was ON_DEMAND. Also, most services installed by HostControllerService and ApplicationServerService are themselves dependencies of DomainModelControllerService and ServerService (which provide the ModelController) so if they are not started no management ops can proceed. But the code would be more robust if the way these were installed involved logic that led to them being tracked by the StabilityMonitor used by ContainerStateMonitor. Doing this would help ensure that future services like this don't fall into a crack the way ExternalManagementRequestExecutor did.
> Note -- I don't think DomainModelControllerService and ServerService themselves should be monitored. Not HostControllerService and ApplicationServerService either.
> Here's some analysis I did when trying to figure out WFCORE-3624:
> HostControllerService
> ---------------------
> ProcessControllerConnectionService -- DMCS depends
> HostControllerExecutorService -- DMCS depends
> HostPathManagerService - DMCS depends
> HostControllerScheduledExecutorService -- no dep
> Value<ProductConfig> -- no dep
> ExternalManagementRequestExecutor -- no dep
> ApplicationServerService
> ------------------------
> ContentRepositoryImpl or RemoteFileRepositoryService -- SS depends
> ContentCleanerService -- no dep
> ServerDeploymentRepositoryImpl -- SS depends
> ServiceModuleLoader -- SS depends
> ExternalModuleService -- SS depends
> ServerPathManagerService -- SS depends
> ServerEnvironmentService -- no dep
> Value<ProductConfig> -- no dep
> ServerExecutorService -- SS dep *if* executor is configured
> ServerScheduledExecutorService -- no dep
> ExternalManagementRequestExecutor -- no dep
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2528) GIT clone ssh not working with java 8 > u111 in drools workbench
by Alexandre Porcelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2528?page=com.atlassian.jira.plugi... ]
Alexandre Porcelli commented on DROOLS-2528:
--------------------------------------------
[~lpetrovicky] fyi
> GIT clone ssh not working with java 8 > u111 in drools workbench
> ----------------------------------------------------------------
>
> Key: DROOLS-2528
> URL: https://issues.jboss.org/browse/DROOLS-2528
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.5.0.Final, 7.7.0.Final
> Environment: CentOS 7, Java 8 u111, Java 8 u161, Java 9, Java 10
> Reporter: Alexander Revkov
> Assignee: Alexandre Porcelli
> Priority: Critical
>
> I cloned my repo by git-ssh ssh://my_ip:8080/myrepo
> If i run drools workbench with java 8 u111. This work is fine. But when i try run workbench with latest version of java 8u161, 9 or 10. clone with ssh not working. I see this exception in log:
> {code:java}
> Exception caught: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> at sun.security.provider.DSA.checkKey(DSA.java:111)
> at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> at java.security.Signature$Delegate.engineInitSign(Signature.java:1178)
> at java.security.Signature.initSign(Signature.java:531)
> at org.apache.sshd.common.signature.AbstractSignature.init(AbstractSignature.java:47)
> at org.apache.sshd.server.kex.AbstractDHGServer.next(AbstractDHGServer.java:91)
> at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:393)
> at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:295)
> at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:731)
> at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:277)
> at org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
> at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:187)
> at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:173)
> at org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker$2.run(Invoker.java:218)
> at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Maybe this is related to this? http://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html
> If yes what users need do to fix it? Else, please fix it. Thank you.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client occasionally hangs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
David Lloyd edited comment on WFLY-9900 at 5/7/18 2:15 PM:
-----------------------------------------------------------
This might be the same issue as WFLY-10150. I'm working on a _possible_ fix for that issue now.
was (Author: dmlloyd):
This might be the same issue as WFLY-10105. I'm working on a _possible_ fix for that issue now.
> EJB client occasionally hangs
> -----------------------------
>
> Key: WFLY-9900
> URL: https://issues.jboss.org/browse/WFLY-9900
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Beta1
> Reporter: Richard Janík
> Assignee: David Lloyd
> Attachments: threaddump-client.txt, threaddump-server1.txt, threaddump-server2.txt, threaddump-server3.txt, threaddump-server4.txt
>
>
> Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
> In two ouf our tests, we saw a small number of clients hang at the end. The scenarios are:
> [jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
> [shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
> The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
> No thread dump as I didn't manage to reproduce yet.
> Might be related to JBEAP-12074 or JBEAP-13169.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months