[JBoss JIRA] (WFCORE-3649) 'deploy' command mandates use of --replace but fails with "Unrecognized arguments: [--replace]"
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3649?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-3649:
-----------------------------------------
Priority: Blocker (was: Major)
That is a regression against 7.1. I would like this one to be in WF12, that has no critical impact but makes for a non user friendly experience.
> 'deploy' command mandates use of --replace but fails with "Unrecognized arguments: [--replace]"
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3649
> URL: https://issues.jboss.org/browse/WFCORE-3649
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Jean-Francois Denise
> Priority: Blocker
>
> {noformat}
> [rhusar@syrah x]$ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] deploy ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> [standalone@localhost:9990 /] deploy ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> org.jboss.as.cli.CommandFormatException: 'clusterbench-ee7.ear' already exists in the deployment repository (use --replace to replace the existing content in the repository).
> [standalone@localhost:9990 /] deploy --replace ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> Unrecognized arguments: [--replace]
> [standalone@localhost:9990 /] deploy --force ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> [standalone@localhost:9990 /]
> {noformat}
> same in domain
> {noformat}
> [domain@localhost:9990 /] deploy --all-server-groups ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> org.jboss.as.cli.CommandFormatException: 'clusterbench-ee7.ear' already exists in the deployment repository (use --replace to replace the existing content in the repository).
> [domain@localhost:9990 /] deploy --all-server-groups --replace ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> Unrecognized arguments: [--replace]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client rarely hangs
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Richard Janík commented on WFLY-9900:
-------------------------------------
I have a job that can reproduce this now (the jvmkill-dist-sync one, not the other), so I'll have a thread dump soon too. About blocker - I created this as major with the idea that later, when I have a good case and a thread dump, I may want to hike the priority higher, but have no strong opinions on what it should be.
[~rhusar] unfortunately at some point, we taught our automation to kill stuck jobs automatically, without teaching it to gather dumps. :)
> EJB client rarely 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
>
> 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 and resist termination 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-9900) EJB client rarely hangs
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9900:
--------------------------------------
Also, note that the java.nio.channels.ClosedChannelException are expected in the JVM kill test, since the JVM is terminated abruptly and there is nothing more the client can do.
> EJB client rarely 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
>
> 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 and resist termination 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-9909) Remoting channel has been closed errors after a node in cluster goes down (legacy ejb client)
by Richard Janík (JIRA)
Richard Janík created WFLY-9909:
-----------------------------------
Summary: Remoting channel has been closed errors after a node in cluster goes down (legacy ejb client)
Key: WFLY-9909
URL: https://issues.jboss.org/browse/WFLY-9909
Project: WildFly
Issue Type: Bug
Components: EJB, Remoting
Affects Versions: 12.0.0.Beta1
Reporter: Richard Janík
We've been seeing this in our clustered ejb failover tests with the legacy (and only legacy) ejb client:
{noformat}
2018/02/20 10:09:51:011 EST [ERROR][Runner - 950] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <javax.ejb.EJBException: java.io.IOException: Channel Channel ID 88395849 (outbound) of Remoting connection 7f615772 to /10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <6949126f> has been closed>
javax.ejb.EJBException: java.io.IOException: Channel Channel ID 88395849 (outbound) of Remoting connection 7f615772 to /10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <6949126f> has been closed
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:240)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:185)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:148)
at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImplLegacyClient$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImplLegacyClient.java:79)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Channel Channel ID 88395849 (outbound) of Remoting connection 7f615772 to /10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <6949126f> has been closed
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:123)
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:115)
at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:50)
at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:520)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:425)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:286)
at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:508)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:150)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.disassociate(RemotingConnectionEJBReceiver.java:273)
at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:458)
at org.jboss.ejb.client.EJBClientContext.unregisterNodeEJBReceivers(EJBClientContext.java:497)
at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:65)
at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
... 1 more
{noformat}
After having a look in the EAP 7.1 jobs, this was the case there as well, so it's not new. The pattern is similar, which is the reason it fell through our checkers, but there are no related NoSuchEjb exceptions here.
These occur fairly often - that is hundreds of times for 2000 clients each making invocations every 4 seconds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client rarely hangs
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9900:
--------------------------------------
Ok, no problem. I have raised the priority to bring attention to a possible blocker problem here (since this might easily fall through the cracks). Though, I agree with David, there is little we can do now without at least the thread dump (but ideally a local and non-SmartFrog reproducer). [~rjanik] I would recommend to always obtain thread dumps before killing a stuck test job.
> EJB client rarely 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
>
> 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 and resist termination 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-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-9892:
----------------------------------
The last test failures pointed out by [~honza889] shows that the issue is not only related with PicketLink STS but wherever signatures are being used. In this case, the same issue happens with PicketLink SAML.
IIRC, the same code is used by both PL STS (WS-Trust) and PL SAML to sign messages.
Is anybody looking this issue already or may I take it ?
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-28) Setup Jenkins Jobs Pipeline for CI
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/SWSQE-28?page=com.atlassian.jira.plugin.s... ]
Hayk Hovsepyan reassigned SWSQE-28:
-----------------------------------
Assignee: Hayk Hovsepyan (was: Sunil kondkar)
> Setup Jenkins Jobs Pipeline for CI
> ----------------------------------
>
> Key: SWSQE-28
> URL: https://issues.jboss.org/browse/SWSQE-28
> Project: Swift Sunshine QE
> Issue Type: Sub-task
> Reporter: Hayk Hovsepyan
> Assignee: Hayk Hovsepyan
>
> New Jenkins jobs pipeline is needed on Jenkins 2 to do the following actions:
> # Trigger per PR
> # Trigger Nightly
> # Call "hawkular-qe-utils.git/tree/sws/scripts/prepare_env.sh" to install Istio on OC
> # Call "hawkular-qe-utils.git/tree/sws/scripts/prepare_env.sh" to install SWS on OC
> # Run SWSQE automation over SWS.
> # Report the Run results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3649) 'deploy' command mandates use of --replace but fails with "Unrecognized arguments: [--replace]"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3649?page=com.atlassian.jira.plugi... ]
Radoslav Husar reassigned WFCORE-3649:
--------------------------------------
Assignee: Jean-Francois Denise (was: Radoslav Husar)
> 'deploy' command mandates use of --replace but fails with "Unrecognized arguments: [--replace]"
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3649
> URL: https://issues.jboss.org/browse/WFCORE-3649
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Jean-Francois Denise
>
> {noformat}
> [rhusar@syrah x]$ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] deploy ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> [standalone@localhost:9990 /] deploy ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> org.jboss.as.cli.CommandFormatException: 'clusterbench-ee7.ear' already exists in the deployment repository (use --replace to replace the existing content in the repository).
> [standalone@localhost:9990 /] deploy --replace ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> Unrecognized arguments: [--replace]
> [standalone@localhost:9990 /] deploy --force ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> [standalone@localhost:9990 /]
> {noformat}
> same in domain
> {noformat}
> [domain@localhost:9990 /] deploy --all-server-groups ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> org.jboss.as.cli.CommandFormatException: 'clusterbench-ee7.ear' already exists in the deployment repository (use --replace to replace the existing content in the repository).
> [domain@localhost:9990 /] deploy --all-server-groups --replace ~/git/clusterbench/clusterbench-ee7-ear/target/clusterbench-ee7.ear
> Unrecognized arguments: [--replace]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months