January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4273) EJBClient message "Unsupported message received with header 0xffffffff" generated when reconnecting to a non-clustered server

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created WFLY-4273: ----------------------------------------- Summary: EJBClient message "Unsupported message received with header 0xffffffff" generated when reconnecting to a non-clustered server Key: WFLY-4273 URL: https://issues.jboss.org/browse/WFLY-4273 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 8.0.0.Final Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz The EJBClient protocol handler on the server side, org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver, will send out a full cluster topology report to a connecting EJBClient. This will happen in particular when the client reconnects after a server which was initially up went down and came up again. If the server is not clustered, the report gets sent out anyway, and erroneously with an empty message body. This message gets processed on the client side by org.jboss.ejb.client.remoting.ChannelAssociation.processResponse() which cannot recognize the message header. The exception results. One way to fix this is to only send out the cluster topology message if the node is actually clustered. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4272?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed WFLY-4272. --------------------------------- Resolution: Duplicate Issue Duplicate of JBJCA-1244 > Data inconsistency for CMR when connection is broken after database resource commits > ------------------------------------------------------------------------------------ > > Key: WFLY-4272 > URL: https://issues.jboss.org/browse/WFLY-4272 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Tom Jenkinson > Assignee: Jesper Pedersen > > Cloned from: > https://bugzilla.redhat.com/show_bug.cgi?id=1181132 > Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote: > We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction. > That ends in situation where db resource was committed and other XA participants are rollbacked. > This is test flow: > - prepare DB xa resource > - prepare test xa resource > - commit DB xa resource > - DB commits > - before confirmation is received by TM the connection crashes > - jdbc driver returns XAException.XA_RBROLLBACK as connection is down > - doAbort is called for the transaction > - test xa resource is rollbacked > - doForget is called and no information about the inconsistent transaction remains in object store > - recovery manager does nothing -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-4272?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-4272: -------------------------------- Issue Type: Bug (was: Feature Request) > Data inconsistency for CMR when connection is broken after database resource commits > ------------------------------------------------------------------------------------ > > Key: WFLY-4272 > URL: https://issues.jboss.org/browse/WFLY-4272 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Tom Jenkinson > Assignee: Jesper Pedersen > > Cloned from: > https://bugzilla.redhat.com/show_bug.cgi?id=1181132 > Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote: > We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction. > That ends in situation where db resource was committed and other XA participants are rollbacked. > This is test flow: > - prepare DB xa resource > - prepare test xa resource > - commit DB xa resource > - DB commits > - before confirmation is received by TM the connection crashes > - jdbc driver returns XAException.XA_RBROLLBACK as connection is down > - doAbort is called for the transaction > - test xa resource is rollbacked > - doForget is called and no information about the inconsistent transaction remains in object store > - recovery manager does nothing -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-4272: ----------------------------------- Summary: Data inconsistency for CMR when connection is broken after database resource commits Key: WFLY-4272 URL: https://issues.jboss.org/browse/WFLY-4272 Project: WildFly Issue Type: Feature Request Components: JCA Reporter: Tom Jenkinson Assignee: Jesper Pedersen Cloned from: https://bugzilla.redhat.com/show_bug.cgi?id=1181132 Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote: We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction. That ends in situation where db resource was committed and other XA participants are rollbacked. This is test flow: - prepare DB xa resource - prepare test xa resource - commit DB xa resource - DB commits - before confirmation is received by TM the connection crashes - jdbc driver returns XAException.XA_RBROLLBACK as connection is down - doAbort is called for the transaction - test xa resource is rollbacked - doForget is called and no information about the inconsistent transaction remains in object store - recovery manager does nothing -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4272?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4272: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1181132 > Data inconsistency for CMR when connection is broken after database resource commits > ------------------------------------------------------------------------------------ > > Key: WFLY-4272 > URL: https://issues.jboss.org/browse/WFLY-4272 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Tom Jenkinson > Assignee: Jesper Pedersen > > Cloned from: > https://bugzilla.redhat.com/show_bug.cgi?id=1181132 > Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote: > We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction. > That ends in situation where db resource was committed and other XA participants are rollbacked. > This is test flow: > - prepare DB xa resource > - prepare test xa resource > - commit DB xa resource > - DB commits > - before confirmation is received by TM the connection crashes > - jdbc driver returns XAException.XA_RBROLLBACK as connection is down > - doAbort is called for the transaction > - test xa resource is rollbacked > - doForget is called and no information about the inconsistent transaction remains in object store > - recovery manager does nothing -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1173493|https://bugzilla.redhat.com/show_bug.cgi?id=1173493] from ON_QA to VERIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-692) Can't resolve declared types in decision tables

by Marc Dzaebel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-692?page=com.atlassian.jira.plugin... ] Marc Dzaebel updated DROOLS-692: -------------------------------- Description: Can't resolve _declared types_ within .drl in decision tables. With only two .drl files, the problem does not occur! Howerver, an additional .xls file seems to disrupt the import of declared types even for .drl files. According to forum entries, it seems that this kind of problem exists about half a decade. (was: Can't resolve _declared types_ within .drl in decision tables. With only two .drl files, the problem does not occur! Howerver, an additional .xls file seems to disrupt the import of declared types even for .drl files.) > Can't resolve declared types in decision tables > ----------------------------------------------- > > Key: DROOLS-692 > URL: https://issues.jboss.org/browse/DROOLS-692 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.CR4 > Environment: Win7, Office 356, JDK 8_u40, Eclipse-Luna, Compiler-Compliance: 1.8 > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Labels: DecisionTables, DeclaredTypes > Attachments: DecisionTableTest.java, Sample.drl, Sample.xls > > > Can't resolve _declared types_ within .drl in decision tables. With only two .drl files, the problem does not occur! Howerver, an additional .xls file seems to disrupt the import of declared types even for .drl files. According to forum entries, it seems that this kind of problem exists about half a decade. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

by Liu Yan (JIRA)

[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ] Liu Yan commented on DROOLS-185: -------------------------------- Masters, please, is there any work around for this issue? > ClassCastException at ConditionEvaluator > ---------------------------------------- > > Key: DROOLS-185 > URL: https://issues.jboss.org/browse/DROOLS-185 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Sergey Alaev > Assignee: Mario Fusco > > Stacktrace: > Caused by: java.lang.ClassCastException: ***** cannot be cast to ****** > at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318) > at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116) > at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > Reason: > ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments. > Given following: > interface A { > String getString(); > } > interface B { > String getString(); > } > class X implements B, A {} > class Y implements A{} > rule "test rule" > when: > A(string != null) > then: > end > When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B. > Thus second call with instance of class Y will cause ClassCastException of casting Y to B. > Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A. > Quickfix: use following declaration of class X: > class X implements A, B {} > Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-692) Can't resolve declared types in decision tables

by Marc Dzaebel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-692?page=com.atlassian.jira.plugin... ] Marc Dzaebel updated DROOLS-692: -------------------------------- Description: Can't resolve _declared types_ within .drl in decision tables. With only two .drl files, the problem does not occur! Howerver, an additional .xls file seems to disrupt the import of declared types even for .drl files. (was: Can't resolve _declared types_ within .drl in decision tables. ) > Can't resolve declared types in decision tables > ----------------------------------------------- > > Key: DROOLS-692 > URL: https://issues.jboss.org/browse/DROOLS-692 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.CR4 > Environment: Win7, Office 356, JDK 8_u40, Eclipse-Luna, Compiler-Compliance: 1.8 > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Labels: DecisionTables, DeclaredTypes > Attachments: DecisionTableTest.java, Sample.drl, Sample.xls > > > Can't resolve _declared types_ within .drl in decision tables. With only two .drl files, the problem does not occur! Howerver, an additional .xls file seems to disrupt the import of declared types even for .drl files. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-112) JBoss Logging doesn't recognize log4j implementation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-112?page=com.atlassian.jira.plu... ] David Lloyd updated JBLOGGING-112: ---------------------------------- Fix Version/s: 3.2.1.Final > JBoss Logging doesn't recognize log4j implementation > ---------------------------------------------------- > > Key: JBLOGGING-112 > URL: https://issues.jboss.org/browse/JBLOGGING-112 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Final, 3.3.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: James Perkins > Fix For: 3.2.1.Final, 3.3.0.Alpha1 > > > There seems to be a typo in org.jboss.logging.LoggingProviders in the method tryLog4j(): the logging provider implementation used is Log4j2LoggerProvider, whereas it should be Log4jLoggerProvider. > The net effect is that if I have log4j jars on the classpath and include a log4j configuration, the configuration gets parsed but log4j is not used as the logging provider; instead, JDK logging provider is used. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015