[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka updated WFLY-10837:
-----------------------------------
Description:
If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
{code}
<orb socket-binding="iiop"/>
{code}
The server starts with error
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
... 8 more
{code}
The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
{code}
"socket-binding" => {
"type" => STRING,
"description" => "The name of the socket binding configuration that specifies the ORB port.",
"attribute-group" => "orb",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
{code}
Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
Up to that
was:
If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
{code}
{code}
The server starts with error
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
... 8 more
{code}
The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
{code}
"socket-binding" => {
"type" => STRING,
"description" => "The name of the socket binding configuration that specifies the ORB port.",
"attribute-group" => "orb",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
{code}
Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
Up to that
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-10837:
--------------------------------------
Summary: IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
Key: WFLY-10837
URL: https://issues.jboss.org/browse/WFLY-10837
Project: WildFly
Issue Type: Bug
Components: IIOP
Reporter: Ondra Chaloupka
Assignee: Tomasz Adamski
If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
{code}
{code}
The server starts with error
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
... 8 more
{code}
The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
{code}
"socket-binding" => {
"type" => STRING,
"description" => "The name of the socket binding configuration that specifies the ORB port.",
"attribute-group" => "orb",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
{code}
Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
Up to that
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-106) JMSDesination and ReplyTo address contain different names to those set on sender
by Martyn Taylor (JIRA)
Martyn Taylor created WFWIP-106:
-----------------------------------
Summary: JMSDesination and ReplyTo address contain different names to those set on sender
Key: WFWIP-106
URL: https://issues.jboss.org/browse/WFWIP-106
Project: WildFly WIP
Issue Type: Bug
Components: Artemis, JMS
Reporter: Martyn Taylor
Assignee: Martyn Taylor
Priority: Blocker
The name of the JMSDestination (when using default producer destination) and ReplyTo addresses of a message do not match the consumed message. This looks to be cause be the adding of prefixes to the destination name before the messages are forwarded to the consumer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-105) [RFE EAP7-1014] Pooled connection factory with discovery group doesn't work
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-105?page=com.atlassian.jira.plugin.... ]
Martin Styk updated WFWIP-105:
------------------------------
Summary: [RFE EAP7-1014] Pooled connection factory with discovery group doesn't work (was: [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work)
> [RFE EAP7-1014] Pooled connection factory with discovery group doesn't work
> ---------------------------------------------------------------------------
>
> Key: WFWIP-105
> URL: https://issues.jboss.org/browse/WFWIP-105
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Martin Styk
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Attachments: standalone-full-ha-node1.xml, standalone-full-ha-node2.xml
>
>
> Scenario:
> Node1 w/o Artemis server has PCF with discovery group
> {noformat}
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
> <discovery-group name="dg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster"/>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" discovery-group="dg-group1" transaction="xa"/>
> <external-jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue"/>
> <external-jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue"/>
> </subsystem>
> {noformat}
> Node2 w/ Artemis server has broadcast group
> {noformat}
> <server>
> <broadcast-group name="bg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster" connectors="connector"/>
> <http-connector name="connector" socket-binding="http" endpoint="acceptor"/>
> <http-acceptor name="acceptor" http-listener="default"/>
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> <jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue" durable="true"/>
> ....
> </server>
> {noformat}
> For full configuration please see attached xmls.
> MDB is deployed to Node1. It should use RA(PCF) to read messages from node2. However it can not connect.
> {noformat}
> 15:51:51,738 ERROR [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@64121323 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:311) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:658) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:698) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
> at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {noformat}
> Same scenario works with connectors. This is *blocker* EAP7-1014.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-105) [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
by Martin Styk (JIRA)
Martin Styk created WFWIP-105:
---------------------------------
Summary: [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
Key: WFWIP-105
URL: https://issues.jboss.org/browse/WFWIP-105
Project: WildFly WIP
Issue Type: Bug
Components: Artemis, JMS
Reporter: Martin Styk
Assignee: ehsavoie Hugonnet
Priority: Blocker
Attachments: standalone-full-ha-node1.xml, standalone-full-ha-node2.xml
Scenario:
Node1 w/o Artemis server has PCF with discovery group
{noformat}
<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
<discovery-group name="dg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" discovery-group="dg-group1" transaction="xa"/>
<external-jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue"/>
<external-jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue"/>
</subsystem>
{noformat}
Node2 w/ Artemis server has broadcast group
{noformat}
<server>
<broadcast-group name="bg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster" connectors="connector"/>
<http-connector name="connector" socket-binding="http" endpoint="acceptor"/>
<http-acceptor name="acceptor" http-listener="default"/>
<jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
<jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue" durable="true"/>
....
</server>
{noformat}
For full configuration please see attached xmls.
MDB is deployed to Node1. It should use RA(PCF) to read messages from node2. However it can not connect.
{noformat}
15:51:51,738 ERROR [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@64121323 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:311) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:658) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:698) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69)
at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809)
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{noformat}
Same scenario works with connectors. This is *blocker* EAP7-1014.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-105) [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-105?page=com.atlassian.jira.plugin.... ]
Martin Styk updated WFWIP-105:
------------------------------
Attachment: standalone-full-ha-node1.xml
> [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
> --------------------------------------------------------------------------
>
> Key: WFWIP-105
> URL: https://issues.jboss.org/browse/WFWIP-105
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Martin Styk
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Attachments: standalone-full-ha-node1.xml, standalone-full-ha-node2.xml
>
>
> Scenario:
> Node1 w/o Artemis server has PCF with discovery group
> {noformat}
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
> <discovery-group name="dg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster"/>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" discovery-group="dg-group1" transaction="xa"/>
> <external-jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue"/>
> <external-jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue"/>
> </subsystem>
> {noformat}
> Node2 w/ Artemis server has broadcast group
> {noformat}
> <server>
> <broadcast-group name="bg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster" connectors="connector"/>
> <http-connector name="connector" socket-binding="http" endpoint="acceptor"/>
> <http-acceptor name="acceptor" http-listener="default"/>
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> <jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue" durable="true"/>
> ....
> </server>
> {noformat}
> For full configuration please see attached xmls.
> MDB is deployed to Node1. It should use RA(PCF) to read messages from node2. However it can not connect.
> {noformat}
> 15:51:51,738 ERROR [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@64121323 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:311) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:658) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:698) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
> at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {noformat}
> Same scenario works with connectors. This is *blocker* EAP7-1014.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-105) [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
by Martin Styk (JIRA)
[ https://issues.jboss.org/browse/WFWIP-105?page=com.atlassian.jira.plugin.... ]
Martin Styk updated WFWIP-105:
------------------------------
Attachment: standalone-full-ha-node2.xml
> [RFE EAP7-1014] Pooled connection factorywith discovery group doesn't work
> --------------------------------------------------------------------------
>
> Key: WFWIP-105
> URL: https://issues.jboss.org/browse/WFWIP-105
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Martin Styk
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
> Attachments: standalone-full-ha-node1.xml, standalone-full-ha-node2.xml
>
>
> Scenario:
> Node1 w/o Artemis server has PCF with discovery group
> {noformat}
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
> <discovery-group name="dg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster"/>
> <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" discovery-group="dg-group1" transaction="xa"/>
> <external-jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue"/>
> <external-jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue"/>
> </subsystem>
> {noformat}
> Node2 w/ Artemis server has broadcast group
> {noformat}
> <server>
> <broadcast-group name="bg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster" connectors="connector"/>
> <http-connector name="connector" socket-binding="http" endpoint="acceptor"/>
> <http-acceptor name="acceptor" http-listener="default"/>
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> <jms-queue name="OutQueue" entries="jms/queue/OutQueue java:jboss/exported/jms/queue/OutQueue" durable="true"/>
> ....
> </server>
> {noformat}
> For full configuration please see attached xmls.
> MDB is deployed to Node1. It should use RA(PCF) to read messages from node2. However it can not connect.
> {noformat}
> 15:51:51,738 ERROR [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@64121323 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:311) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:658) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:698) [artemis-ra-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
> at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809)
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {noformat}
> Same scenario works with connectors. This is *blocker* EAP7-1014.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10836) mod_cluster uses wrong password for credential stores (regression after removing lambdas)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10836?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10836:
----------------------------------
Workaround Description: Due to use of toString on a ModelNode as opposed to asString, there are extra quotes added around the password; using quoted password would workaround the problem.
Workaround: Workaround Exists
> mod_cluster uses wrong password for credential stores (regression after removing lambdas)
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-10836
> URL: https://issues.jboss.org/browse/WFLY-10836
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Final, 13.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> Uncovered by [~jkasik].
> Credential stores are opened with wrong password. Regression caused by WFLY-9613 [1].
> {code}
> 09:43:29,686 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:113)
> at org.wildfly.extension.mod_cluster.ProxyConfigurationServiceConfigurator.configure(ProxyConfigurationServiceConfigurator.java:315)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemServiceHandler.installServices(ModClusterSubsystemServiceHandler.java:79)
> at org.jboss.as.clustering.controller.AddStepHandler.performRuntime(AddStepHandler.java:179)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:338)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
> at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
> at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
> at java.security.KeyStore.load(KeyStore.java:1445)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getStore(JSSESocketFactory.java:230)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeystore(JSSESocketFactory.java:179)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:251)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.<init>(JSSESocketFactory.java:98)
> ... 15 more
> Caused by: java.security.UnrecoverableKeyException: Password verification failed
> at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:778)
> ... 23 more
> {code}
> [1] https://github.com/wildfly/wildfly/pull/10708/files#diff-fabeb2ec71da4fca...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10795?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10795:
---------------------------------------
The issue has been identified as https://issues.jboss.org/browse/WFLY-10836 (regression since WF12). PR is updated.
> Non-Elytron SSL configuration won't establish secure channel between worker and balancer
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-10795
> URL: https://issues.jboss.org/browse/WFLY-10795
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: No Release
> Environment: Latest snapshot from ci.wildfly.org
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
> Attachments: confs.zip
>
>
> When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer.
> Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel.
> I enabled SSL debugging, and such unsecured-secured communication causes this error:
> {code}
> 09:42:20,456 INFO [stdout] (default I/O-4) Using SSLEngineImpl.
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow unsafe renegotiation: false
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow legacy hello messages: true
> 09:42:20,458 INFO [stdout] (default I/O-4) Is initial handshake: true
> 09:42:20,459 INFO [stdout] (default I/O-4) Is secure renegotiation: false
> 09:42:20,459 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,479 INFO [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record
> 09:42:20,480 INFO [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT: fatal, description = internal_error
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeInbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeOutbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, closeOutboundInternal()
> {code}
> What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from:
> {code}
> 09:45:42,653 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> {code}
> Configuration using non-Elytron configuration was possible before, hence this is a regression.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10834) Load provider settings is not taken into account in mod_cluster subsystem
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10834?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10834:
----------------------------------
Affects Version/s: No Release
(was: 14.0.0.CR1)
> Load provider settings is not taken into account in mod_cluster subsystem
> -------------------------------------------------------------------------
>
> Key: WFLY-10834
> URL: https://issues.jboss.org/browse/WFLY-10834
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: No Release
> Environment: Latest nightly from ci.wildfly.org
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 14.0.0.CR1
>
>
> Everything works in version with old subsytem with this settings (load is properly reported to balancer):
> {code:xml}
> <subsystem
> xmlns="urn:jboss:domain:modcluster:3.0">
> <mod-cluster-config advertise-socket="modcluster" auto-enable-contexts="true" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Same configuration for latest snapshot doesn't work (load remains at 1):
> {code:xml}
> <subsystem
> xmlns="urn:jboss:domain:modcluster:4.0">
> <proxy name="default" advertise-socket="modcluster" auto-enable-contexts="true" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu" weight="1"/>
> </dynamic-load-provider>
> </proxy>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months