[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 commented on WFLY-9900:
-----------------------------------
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
[JBoss JIRA] (WFLY-3466) No error reported when remote handshake fails
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3466?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-3466.
-------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
> No error reported when remote handshake fails
> ---------------------------------------------
>
> Key: WFLY-3466
> URL: https://issues.jboss.org/browse/WFLY-3466
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: David Lloyd
> Fix For: 11.0.0.Final
>
>
> When the destination server fails to respond and thus the remote handshake cannot be made, nothing gets reported in the client's log -- even when put on TRACE. I spent many days trying to get to the bottom of this. This abnormal condition is too important for it to go unreported.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-3923) Option for suppressing thread interruption during JDBC driver operations
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3923?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3923:
-----------------------------------
We could combine this idea with an InterruptHandler which causes the in-progress Statement to be cancelled. It could be configurable: interrupt could do nothing, be passed through, or cause cancel (where applicable).
> Option for suppressing thread interruption during JDBC driver operations
> ------------------------------------------------------------------------
>
> Key: WFLY-3923
> URL: https://issues.jboss.org/browse/WFLY-3923
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Reporter: David Lloyd
> Assignee: Jesper Pedersen
>
> The data source and JCA subsystems should provide a facility to suppress thread interruption during driver operations. The data source attribute should have values "on", "off", and "auto", where "auto" indicates that the subsystem should make a decision based on the driver.
> A list of drivers which are known to fail in the presence of interruption is forthcoming.
> A facility in JBoss Threads to suppress interruption for the duration of a task is forthcoming.
--
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:
--------------------------------------------
[~aarevkov] thank you for your feedback. Is it a bug? If yes... this is a Java issue, that can't handle older certs =/
> 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-10338) Discovery subsystem is missing from the domain profiles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10338?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10338:
---------------------------------------
Assignee: Yeray Borges (was: Brian Stansberry)
[~yersan] Can you handle this one? I took it from Alexey but am giving it away. :)
The WFCORE-3784 fix shows the basic thing that needs to be done, except in full feature-pack there are more profiles. Check with [~dmlloyd] which profiles should have this subsystem. It should be in full and full-ha for sure; and not in load-balancer. The others, I'm not sure.
Doing that will break the mixed-domain tests, same way the special tests of aloubyansky/galleon-pack are broken. The mixed domain tests have this concept of a DomainAdjuster which tweaks the DC config to remove things that are known to be unusable on legacy slaves. So those will need to be tweaked to account for this discovery subsystem being in the config.
Fixing the mixed-domain tests for this will fix the failures in aloubyansky/galleon-pack as well.
> Discovery subsystem is missing from the domain profiles
> -------------------------------------------------------
>
> Key: WFLY-10338
> URL: https://issues.jboss.org/browse/WFLY-10338
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Fix For: 13.0.0.Beta1
>
>
> Same problem as WFCORE-3784 except in the full feature-pack.
--
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 Alexander Revkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2528?page=com.atlassian.jira.plugi... ]
Alexander Revkov commented on DROOLS-2528:
------------------------------------------
[~porcelli] Hello. This is not a clean installation. I install wild fly with java 8 u111, then update my java to 8u161 and git-ssh break. Try delete .security folder fixed it. This is normal? This is not a bug?
> 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-3558) Wildfly throws misleading exception for EJB misimplementation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3558?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-3558.
-------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
> Wildfly throws misleading exception for EJB misimplementation
> -------------------------------------------------------------
>
> Key: WFLY-3558
> URL: https://issues.jboss.org/browse/WFLY-3558
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Randahl Fink Isaksen
> Fix For: 11.0.0.Final
>
>
> I invoked a method on one of my EJBs and got the exception below on the client side. The problem is, this exception is quite misleading. I found out, that the problem went away after I corrected my EJB's method – It had a parameter which was not Serializable.
> I suggest throwing a more meaningful AParameterDidNotImplementSerializableException in this situation – that would have saved me hours of debugging.
> java.lang.IllegalStateException: EJBCLIENT000051: Cannot proceed with invocation since the locator StatefulEJBLocator{appName='wefend-server', moduleName='wefend-ejb', distinctName='', beanName='InstallBean', view='interface com.wefend.services.install.InstallService', sessionId='{[-71, -73, -47, 40, -82, 13, 67, -49, -112, -55, 33, 50, 42, -94, -102, -104]}'} has an affinity on node zirconium which has been excluded from current invocation context org.jboss.ejb.client.EJBClientInvocationContext@33c102c9
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:208)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy4.install(Unknown Source)
> at com.wefend.observatory.install.task.InstallTask.call(InstallTask.java:91)
> at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:744)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10339:
-------------------------------------
[~jmesnil] If you concur with the suggestion - feel free to assign to me.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-10339:
--------------------------------
Description:
Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
I suggest splitting these resources into 2:
{code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
{code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
which requires clustering capabilities
and
{code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
{code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
which requires a socket-binding capability.
This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
was:
Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
I suggest splitting these resources into 2:
{code}/server=*/jgroups-broadcast-group=*{code}
{code}/server=*/jgroups-discovery-group=*{code}
which requires clustering capabilities
and
{code}/server=*/socket-broadcast-group=*{code}
{code}/server=*/socket-discovery-group=*{code}
which requires a socket-binding capability.
This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-10339:
--------------------------------
Description:
Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
I suggest splitting these resources into 2:
{code}/server=*/jgroups-broadcast-group=*{code}
{code}/server=*/jgroups-discovery-group=*{code}
which requires clustering capabilities
and
{code}/server=*/socket-broadcast-group=*{code}
{code}/server=*/socket-discovery-group=*{code}
which requires a socket-binding capability.
This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
was:
Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
I suggest splitting these resources into 2:
/server=*/jgroups-broadcast-group=*
/server=*/jgroups-discovery-group=*
which requires clustering capabilities
and
/server=*/socket-broadcast-group=*
/server=*/socket-discovery-group=*
which requires a socket-binding capability.
This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/server=*/jgroups-broadcast-group=*{code}
> {code}/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/server=*/socket-broadcast-group=*{code}
> {code}/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months