[JBoss JIRA] (WFLY-9670) Add the subordinate orphan filters and recovery module for Narayana
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-9670?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-9670:
--------------------------------
Description:
There is a missing orphan filter in Narayana that should be added to the WFLY default configuration.
Without it there is a data integrity issue as competing remote servers may rollback each others branches.
was:
There are some missing orphan filters in Narayana that should be added to the WFLY default configuration.
Without them there is a data integrity issue as competing remote servers may rollback each others branches.
> Add the subordinate orphan filters and recovery module for Narayana
> -------------------------------------------------------------------
>
> Key: WFLY-9670
> URL: https://issues.jboss.org/browse/WFLY-9670
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 12.0.0.Alpha1
>
>
> There is a missing orphan filter in Narayana that should be added to the WFLY default configuration.
> Without it there is a data integrity issue as competing remote servers may rollback each others branches.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9670) Add the subordinate orphan filters for Narayana
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-9670:
-----------------------------------
Summary: Add the subordinate orphan filters for Narayana
Key: WFLY-9670
URL: https://issues.jboss.org/browse/WFLY-9670
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 12.0.0.Alpha1
There are some missing orphan filters in Narayana that should be added to the WFLY default configuration.
Without them there is a data integrity issue as competing remote servers may rollback each others branches.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9665) HttpSession cannot be injected in distributed application
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9665?page=com.atlassian.jira.plugin.... ]
Martin Kouba resolved WFLY-9665.
--------------------------------
Resolution: Won't Do
> HttpSession cannot be injected in distributed application
> ---------------------------------------------------------
>
> Key: WFLY-9665
> URL: https://issues.jboss.org/browse/WFLY-9665
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 10.1.0.Final
> Reporter: Zoltan Laszlo Ferenci
> Assignee: Martin Kouba
> Attachments: HttpSessionInjectionBug.zip
>
>
> The CDI Specification states that HttpSession should be available for injection. It also has statements about when should the bean passivation capable.
> The problem is that it seems the io.undertow.servlet.spec.HttpSessionImpl is not serializable, and whenever you try to inject, you get exception at passivation.
> I would say it's normal if it's injected into a passivating scoped bean, because the CDI specification says that the bean is passivation capable only if all it's dependencies is passivation capable.
> However this is the case even if it's injected in a RequestScoped bean, that shouldn't be passivated. In the sample project only the HttpSession should be passivated that is independent from the CDI. Anyway it gives an error in that case too, and doesn't store and recover the HttpSession.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9665) HttpSession cannot be injected in distributed application
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9665?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-9665:
------------------------------------
Hello Zoltan, this is a known issue - WELD-2346, it's fixed in Weld 2.4.3 and 3.0.0. You should either upgrade to WildFly 11.0.0.Final or use the latest Weld 2.4 patch for 10.1.0: http://download.jboss.org/weld/2.4.5.Final/wildfly-10.1.0.Final-weld-2.4.....
> HttpSession cannot be injected in distributed application
> ---------------------------------------------------------
>
> Key: WFLY-9665
> URL: https://issues.jboss.org/browse/WFLY-9665
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 10.1.0.Final
> Reporter: Zoltan Laszlo Ferenci
> Assignee: Martin Kouba
> Attachments: HttpSessionInjectionBug.zip
>
>
> The CDI Specification states that HttpSession should be available for injection. It also has statements about when should the bean passivation capable.
> The problem is that it seems the io.undertow.servlet.spec.HttpSessionImpl is not serializable, and whenever you try to inject, you get exception at passivation.
> I would say it's normal if it's injected into a passivating scoped bean, because the CDI specification says that the bean is passivation capable only if all it's dependencies is passivation capable.
> However this is the case even if it's injected in a RequestScoped bean, that shouldn't be passivated. In the sample project only the HttpSession should be passivated that is independent from the CDI. Anyway it gives an error in that case too, and doesn't store and recover the HttpSession.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9502) javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-9502:
-------------------------------
Even the PR: https://github.com/wildfly/wildfly/pull/10749 fixed the modules dependency issue, there is another timeout problem (WFLY-9669) to prevent the create the JMS bridge.
> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9502
> URL: https://issues.jboss.org/browse/WFLY-9502
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 11.0.0.Final
> Reporter: Martin Švehla
> Assignee: Lin Gao
> Priority: Critical
> Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 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}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9669) JMS bridge fails to create session factory with connection timeout between WildFly and EAP 6.4
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-9669?page=com.atlassian.jira.plugin.... ]
Lin Gao moved JBEAP-14086 to WFLY-9669:
---------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9669 (was: JBEAP-14086)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: IIOP
JMS
(was: ActiveMQ)
(was: IIOP)
Affects Version/s: (was: 7.1.0.CR4)
> JMS bridge fails to create session factory with connection timeout between WildFly and EAP 6.4
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9669
> URL: https://issues.jboss.org/browse/WFLY-9669
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, JMS
> Reporter: Lin Gao
> Assignee: Martyn Taylor
>
> When having configured JMS bridge on EAP 7 with target queue on EAP 6.4 after starting the server, after short while I can see that it failed to create session factory with exception \[1\].
> I am also attaching config files of EAP 6.4 server and of EAP 7.1.0.CR4 server.
> \[1\]
> {noformat}
> 2017-11-23 16:49:31,423 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-230) AMQ342010: Failed to connect JMS Bridge N/A: javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.createConnection(JMSBridgeImpl.java:979)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1148)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 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)
> Caused by: HornetQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=HQ119013: Timed out waiting to receive cluster topology. Group:null]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:946)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 10 more
> 2017-11-23 16:49:31,443 INFO [org.apache.activemq.artemis.jms.bridge] (Thread-230) AMQ341000: Failed to set up JMS bridge N/A connections. Most probably the source or target servers are unavailable. Will retry after a pause of 2,500 ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9502) javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-9502:
-------------------------------
As the reproduce steps noted, the exception in question comes from module dependencies, adding dependency of {{org.wildfly.naming-client}} to related modules fix this exception.
> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9502
> URL: https://issues.jboss.org/browse/WFLY-9502
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 11.0.0.Final
> Reporter: Martin Švehla
> Assignee: Lin Gao
> Priority: Critical
> Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 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}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months