[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Yea will get the thread dump on node1 soon. Just to remind you - the failover by "power-off" works on linux environment for Wildfly.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2042:
--------------------------------
Hmm, we could create an abstract method {{Header.getId()}} which returns a constant magic ID. When {{ClassConfigurator}} is initialized, it would check that the magic IDs defined in {{jg-magic-map.xml}} actually match the ones returned by {{getId()}}. In case of a mismatch, an exception would be thrown.
Downside: when IDs change, the corresponding header classes have to be changed, too.
Upside: faster serialization (eliminating 1 hashmap lookup for the magic ID). We only have a limited number of header classes anyway.
> Improve performance of Message#writeHeader
> ------------------------------------------
>
> Key: JGRP-2042
> URL: https://issues.jboss.org/browse/JGRP-2042
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised.
> {noformat}Stack Trace Sample Count Percentage(%)
> java.util.IdentityHashMap.get(Object) 66 2.224
> org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224
> org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224
> {noformat}
> One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1158:
----------------------------------------
Hello [~jcgarciam], I've checked your description and your reproducer, but I would kindly request for your feedback on the following questions, please?
.
* I've run the reproducer but it does not trigger the error/stacktrace you reported. Ref. screenshot:
!screenshot-1.png|thumbnail!
I've just added slf4j-log4j dependency in order to see some drools logs, but your code left unchanged indeed does not reproduce the error/stacktrace you reported.
Additionally, I've tried to increase the timeout in the test, still nothing. I've moved drools version from 6.4.0.Final originally in your reproducer, to 6.3.0.Final as you reported that was also an issue, still nothing. Can you advise on the attached reproducer please, because is not triggering the error/stacktrace you reported.
Then I've explored your code, and I think part of it is using internal API. Based on your use-case scenario reported in the description above (summarizing: _avoiding, as possible, to completely rebuild the KB from the XLS files where most are unchanged_), I'm wondering:
# wouldn't the KieScanner to monitor KJAR update be easier to use for this use-case scenario?
Being the incremental update based at resource level, I was expecting should have addressed your need described.
# if the KieScanner/KJAR usage is not suitable for any reason, wouldn't it be easier to use the public Kie API to build the KieModule in programmatically, say following the example ["4.2.6.10. Programmaticaly build a KieModule using Meta Models"|http://docs.jboss.org/drools/release/6.4.0.Final/drools-docs/html_single/index.html#d0e3917] ?
(trying to anticipate a possible follow-up question, on top of my head with that API I'm not sure you can re-use KiePackages originating from another KieBase, but you should be able to keep the manual caching currently done at least for the rendering of XLS in DRL form?)
I hope this at least partially helps, and kindly awaiting for your feedback; thank you.
MM
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1158:
-----------------------------------
Attachment: screenshot-1.png
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
Problem is that HornetQ connector in SL.war on node 1 is using IP address of node 1 and node 2 power off somehow breaks it. There are no errors/warnings in the log which would indicate what's going on. It seems like nothing happened. Maybe thread dump of Wildfly on node 1 could help where the execution is hanging.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak edited comment on WFLY-6781 at 7/13/16 9:03 AM:
---------------------------------------------------------------
I understood it as power offing of node 2 somehow negatively affected networking on node 1. The point was that the problem is on OS or VM level on node 1.
Edited.
was (Author: mnovak):
I understood it as it power offing of node 2 somehow negatively affected networking on node 2. The point was that the problem is on OS or VM level.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2042:
--------------------------------
The problem is that you cannot avoid the lookup altogether because the mapping between magic IDs and classes is defined in {{jg-magic-map.xml}}. So either the lookup is done at header creation time, or at serialization time; the cost is the same (1 lookup).
If each header class defined its own constant magic ID, that would work, but I don't want to do that as we'd have to make sure all header IDs are unique...
> Improve performance of Message#writeHeader
> ------------------------------------------
>
> Key: JGRP-2042
> URL: https://issues.jboss.org/browse/JGRP-2042
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised.
> {noformat}Stack Trace Sample Count Percentage(%)
> java.util.IdentityHashMap.get(Object) 66 2.224
> org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224
> org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224
> {noformat}
> One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Alright thanks Miroslav.
Just to let you know its only happening on Wildfly-8.2. We have our same application deployed on weblogic 11g in cluster mode and the failover is working fine there without issues.
So perhaps we can conclude that since this issue is happening only on windows for Wildfly, the issue is specific to OS or VM level for Wildfly and not for Weblogic.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6498:
-------------------------------------------
The current issue is related to EJBCLIENT-137 in that the UserTransaction test case in RemoteFailoverTestCase was created in order to test that retry is disabled in the case of EJBCLient UserTransactions being present.
> EJBClient UserTransactions with multiple method invocations generate lock conflicts
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6498
> URL: https://issues.jboss.org/browse/WFLY-6498
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> Using the EJBClient library, we should be able to do the following from a standalone EJBClient application:
> // create a UserTransaction associated with a clustered server node X
> // make an invocation on an EJB on X
> // make an invocation on an EJB on X
> // commit the UserTransaction
> However, doing so results in this exception which occurs during processing of the second invocation:
> {noformat}
> [0m[31m11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> {noformat}
> The exception does not arise if we perform only one invocation within the UserTransaction.
> This exception is repeatable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ELY-587) SSLContext integration into DirContext supplier service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-587?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-587:
---------------------------
Description:
* we already have a resource to define the SSLContext
* we want use it for connection to LDAP
* resource of DirContext supplier (see ELY-462) should reference SSLContext resource / capability
was:
* we already have a resource to define the SSLContext
* we want use it for connection to LDAP
* new resource should return an ExceptionSupplier<DirContext>
* new resource should reference SSLContext resource / capability
> SSLContext integration into DirContext supplier service
> -------------------------------------------------------
>
> Key: ELY-587
> URL: https://issues.jboss.org/browse/ELY-587
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> * we already have a resource to define the SSLContext
> * we want use it for connection to LDAP
> * resource of DirContext supplier (see ELY-462) should reference SSLContext resource / capability
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months