[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Dominik Pospisil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5785?page=com.atlassian.jira.plugin.... ]
Dominik Pospisil commented on WFLY-5785:
----------------------------------------
It seems that the issue is caused by the servers sending CLUSTER_REMOVED message to the clients during node shutdiwn even if the node is not the last one in the cluster.
> EJB lookup fails with "No cluster context available" in failover tests
> ----------------------------------------------------------------------
>
> Key: WFLY-5785
> URL: https://issues.jboss.org/browse/WFLY-5785
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Dominik Pospisil
>
> Seen in our failover tests for remote stateful EJBs - scenarios:
> ejb-ejbremote-shutdown-dist-async
> ejb-ejbremote-shutdown-dist-sync
> ejb-ejbremote-undeploy-dist-async
> After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
> {code}
> 2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
> java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> 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:745)
> {code}
> It stops logging these messages only after the failed node is restarted and joins the cluster again.
> Link (this job was configured to use only 100 sessions in order to keep the log size small)
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1297) deploy --url command creates invalid deployment
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1297?page=com.atlassian.jira.plugi... ]
Martin Simka reassigned WFCORE-1297:
------------------------------------
Assignee: Alexey Loubyansky (was: David Lloyd)
> deploy --url command creates invalid deployment
> -----------------------------------------------
>
> Key: WFCORE-1297
> URL: https://issues.jboss.org/browse/WFCORE-1297
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.6.Final
> Reporter: Martin Simka
> Assignee: Alexey Loubyansky
>
> Command {{deploy --url=http://localhost/test/simple-servlet.war}}
> creates invalid deployment
> According to logs everything seems to be fine
> {noformat}
> 15:03:57,505 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /tmp/jboss-eap-7.0/standalone/data/content/5e/5e5709be9a06a9ed7bcb2100a4143400fea887/content
> 15:03:57,531 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "/test/simple-servlet.war" (runtime-name: "/test/simple-servlet.war")
> 15:03:58,238 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0021: Registered web context: //test/simple-servlet
> 15:03:58,320 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "/test/simple-servlet.war" (runtime-name : "/test/simple-servlet.war")
> {noformat}
> but web context {{http://localhost:8080//test/simple-servlet}} isn't accessible, it returns {{404 - Not Found}}.
> (simple-servlet.war doesn't contain jboss-web.xml, so no context root is defined there)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5989) Remoting requires FilePermission for XNIO and marshalling modules to run with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5989?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-2771 to WFLY-5989:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5989 (was: JBEAP-2771)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Remoting
Security Manager
(was: Remoting)
(was: Security Manager)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR5
(was: 7.0.0.ER4)
> Remoting requires FilePermission for XNIO and marshalling modules to run with security manager
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-5989
> URL: https://issues.jboss.org/browse/WFLY-5989
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Security Manager
> Affects Versions: 10.0.0.CR5
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
>
> Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1297) deploy --url command creates invalid deployment
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1297?page=com.atlassian.jira.plugi... ]
Martin Simka moved JBEAP-2769 to WFCORE-1297:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1297 (was: JBEAP-2769)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: CLI
Domain Management
(was: Class Loading)
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.6.Final
(was: 7.0.0.ER4)
> deploy --url command creates invalid deployment
> -----------------------------------------------
>
> Key: WFCORE-1297
> URL: https://issues.jboss.org/browse/WFCORE-1297
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.6.Final
> Reporter: Martin Simka
> Assignee: David Lloyd
>
> Command {{deploy --url=http://localhost/test/simple-servlet.war}}
> creates invalid deployment
> According to logs everything seems to be fine
> {noformat}
> 15:03:57,505 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /tmp/jboss-eap-7.0/standalone/data/content/5e/5e5709be9a06a9ed7bcb2100a4143400fea887/content
> 15:03:57,531 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "/test/simple-servlet.war" (runtime-name: "/test/simple-servlet.war")
> 15:03:58,238 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0021: Registered web context: //test/simple-servlet
> 15:03:58,320 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "/test/simple-servlet.war" (runtime-name : "/test/simple-servlet.war")
> {noformat}
> but web context {{http://localhost:8080//test/simple-servlet}} isn't accessible, it returns {{404 - Not Found}}.
> (simple-servlet.war doesn't contain jboss-web.xml, so no context root is defined there)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1296) Rejecting the SSL certificate while connecting via CLI block indefinately
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1296?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky moved JBEAP-2767 to WFCORE-1296:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1296 (was: JBEAP-2767)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: CLI
(was: CLI)
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.5.Final
(was: 7.0.0.ER3)
> Rejecting the SSL certificate while connecting via CLI block indefinately
> --------------------------------------------------------------------------
>
> Key: WFCORE-1296
> URL: https://issues.jboss.org/browse/WFCORE-1296
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> Connection to the CLI secured by SSL blocks indefinitely once I refuse to accept the server certificate.
> *reproduce*
> start standalone server and secure ManagementRealm with ssl
> *6.4.0 behaviour*
> {noformat}
> ./jboss-cli.sh -c '/core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(keystore-path=$PATH_TO_KEYSTORE, keystore-password=$PASSWORD), reload'
> ./jboss-cli.sh -c 127.0.0.1:9443
> ...
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : N
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:299)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:265)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:473)
> Caused by: org.jboss.as.cli.CommandLineException: Unable to negotiate SSL connection with controller at localhost:9999
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1048)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:887)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:863)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:297)
> ... 8 more
> $
> {noformat}
> *7.0.0.ER3 behaviour*
> {noformat}
> ./jboss-cli.sh -c
> /core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(keystore-path=/path/to/keystore, keystore-password=password)
> /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding
> /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding,value=management-https)
> reload
> {noformat}
> Connect to the CLI and reject the certificate
> {noformat}
> $ ./jboss-cli.sh --controller=https-remoting://localhost:9993 -c
> ...
> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : N
> {noformat}
> You are stuck at this point, all you can do is to interrupt (Ctrl+C)
> {noformat}
> java.lang.InterruptedException
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220)
> at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)
> at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:400)
> at org.jboss.aesh.console.Console.getInput(Console.java:484)
> at org.jboss.aesh.console.Console.getInputLine(Console.java:528)
> at org.jboss.as.cli.impl.Console$Factory$1.read(Console.java:222)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:197)
> at org.jboss.as.cli.impl.CommandContextImpl.readLine(CommandContextImpl.java:899)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSSLFailure(CommandContextImpl.java:1137)
> at org.jboss.as.cli.impl.CommandContextImpl.access$1200(CommandContextImpl.java:183)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager$1.run(CommandContextImpl.java:1897)
> at org.jboss.as.protocol.GeneralTimeoutHandler.suspendAndExecute(GeneralTimeoutHandler.java:45)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager.checkServerTrusted(CommandContextImpl.java:1892)
> at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:936)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1493)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:93)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
> Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9993
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5988) Get running OpenJDK IIOP component test from OpenJDK sources
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5988?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5988:
----------------------------------------
maybe this is quite a hardly possible task - I've talked with _jvanek(a)redhat.com_ and for what I understood there are only proprietary tests (owned by Oracle) to certify orb implementation - TCK.
Such tests are run on platform certified by openjdk - which is fedora and rhel on intel. There are some tests on windows as well but there is some special guy doing so somewhere in Ireland. It's quite hard to get it running and probably take few weeks to incorporate it to a testing process.
I would leave this as a optional idea for future. From what I've heard it's hard to get it.
> Get running OpenJDK IIOP component test from OpenJDK sources
> ------------------------------------------------------------
>
> Key: WFLY-5988
> URL: https://issues.jboss.org/browse/WFLY-5988
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
> Priority: Minor
>
> It would be good to have running IIOP tests from OpenJDK sources (if there exist some).
> If such tests would be prepared for running I could take them and run on all supported platforms where we could reveal possible troubles. It could be so that OpenJDK team already run them all on all platforms but even in such case it would be good to run them as JBoss has it's own fork of the code [1] and even fixes are backported it could be there some small differences.
> [1] https://code.engineering.redhat.com/gerrit/gitweb?p=jboss%2Fopenjdk-orb.g...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5988) Get running OpenJDK IIOP component test from OpenJDK sources
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-5988:
--------------------------------------
Summary: Get running OpenJDK IIOP component test from OpenJDK sources
Key: WFLY-5988
URL: https://issues.jboss.org/browse/WFLY-5988
Project: WildFly
Issue Type: Enhancement
Components: IIOP
Reporter: Ondřej Chaloupka
Assignee: Tomasz Adamski
Priority: Minor
It would be good to have running IIOP tests from OpenJDK sources (if there exist some).
If such tests would be prepared for running I could take them and run on all supported platforms where we could reveal possible troubles. It could be so that OpenJDK team already run them all on all platforms but even in such case it would be good to run them as JBoss has it's own fork of the code [1] and even fixes are backported it could be there some small differences.
[1] https://code.engineering.redhat.com/gerrit/gitweb?p=jboss%2Fopenjdk-orb.g...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-2002) ByteArrayDataOutputStream: option to grow exponentially
by Bela Ban (JIRA)
Bela Ban created JGRP-2002:
------------------------------
Summary: ByteArrayDataOutputStream: option to grow exponentially
Key: JGRP-2002
URL: https://issues.jboss.org/browse/JGRP-2002
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.8
{{Util.objectTo(Byte)Buffer()}} uses an underlying {{ByteArrayDataOutputStream}} which grows linearly. If we need to marshal a very large or complex object, linear growth will lead to many copies when growing the underlying buffer.
Solution: add an option to grow {{ByteArrayDataOutputStream}} exponentially. This will be used by default by {{Util.objectToByteBuffer()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months