July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13633: ----------------------------------------- This relates to undeploy - does that require a reload? > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5458) Running tests should not affect incremental build

by Jan Stastny (Jira)

[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ] Jan Stastny updated DROOLS-5458: -------------------------------- Summary: Running tests should not affect incremental build (was: Project broken after test scenario run with possibly a class-loading issue) > Running tests should not affect incremental build > ------------------------------------------------- > > Key: DROOLS-5458 > URL: https://issues.redhat.com/browse/DROOLS-5458 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.39.0.Final > Reporter: Jan Stastny > Assignee: Toni Rikkola > Priority: Blocker > Labels: drools-tools > Attachments: bpms_scesim-tickets.zip > > > For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central. > The ultimate error is in the DRL file validation: > {code:java|title=DRL file} > package org.jboss.qa.ba.scesim; > rule "child ticket" > when > t: Ticket ( type==TicketType.CHILD) > then > t.setPrice(5.0); > end > {code} > {code:java|title=Validation error} > [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD: > [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType] > [Near : {... type == TicketType.CHILD ....}] > ^ > {code} > The issue happens in given scenario: > # import project > # go to DRL file and run validation - succeeds > # go to scenario simulation and run - succeeds > # go back to DRL file and run validation - fails with the error above > # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts > The issue disappears when running Build of the project in the Project perspective. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Michael Musgrove commented on WFLY-13633: ----------------------------------------- CMR resources can be added using wildfly CLI operations. I believe those operations require a reload if they are modified. Will that not protect us from the scenario outlined in the JIRA description > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13634) A bootable JAR for WildFly 20

by Gergely Molnár (Jira)

Gergely Molnár created WFLY-13634: ------------------------------------- Summary: A bootable JAR for WildFly 20 Key: WFLY-13634 URL: https://issues.redhat.com/browse/WFLY-13634 Project: WildFly Issue Type: Feature Request Components: Build System Affects Versions: 20.0.0.Final Reporter: Gergely Molnár Assignee: Brian Stansberry This is a great idea, but why not pick up or migrate from Thorntail? This RedHat product based on Wildfly. Full support will end at May 2021 link: https://access.redhat.com/support/policy/updates/jboss_notes I use it instead of install Wildfly and deploy the war files under integration testing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by lukas brandl (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] lukas brandl edited comment on JGRP-2486 at 7/1/20 7:35 AM: ------------------------------------------------------------ I've created a pull request (here: [https://github.com/belaban/JGroups/pull/500]) to split the FD Monitor task into a timeout checker and a heartbeat sender, in the same way as the FD_ALL and FD_ALL2 protocol. This way the timeout check can't be blocket by the TCP transport and the dead node is suspected. was (Author: lbrandl2): I've created a pull request (here: [https://github.com/belaban/JGroups/pull/500]) to split the FD Monitor task into a timeout checker and a heartbeat sender, in the same way as the FD_ALL and FD_ALL2 protocol. This way the timeout check can't be blocket by the TCP transport and the dead nodes is suspected. > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by lukas brandl (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] lukas brandl commented on JGRP-2486: ------------------------------------ I've created a pull request (here: [https://github.com/belaban/JGroups/pull/500]) to split the FD Monitor task into a timeout checker and a heartbeat sender, in the same way as the FD_ALL and FD_ALL2 protocol. This way the timeout check can't be blocket by the TCP transport and the dead nodes is suspected. > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Thomas Jenkinson updated WFLY-13633: ------------------------------------ Description: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. was: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... This means that if Narayana encounters another resource with the same name at a later date it will consider it is a CMR resource. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13632: ----------------------------------------- I think it is a data integrity issue in the sense that a concurrent deploy of CMR resources would mean that one of them would not be treated as a CMR. Possibly though it would be treated as full XA which might mean this is just critical as unexpected behaviour? This needs more investigation. > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13633: ----------------------------------------- I think it is a data integrity issue in the sense that a subsequent deploy of a resource would be treated as a CMR so the behaviour of the resource would not be as expected by the user. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource with the same name at a later date it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Thomas Jenkinson (Jira)

Thomas Jenkinson created WFLY-13633: --------------------------------------- Summary: Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR Key: WFLY-13633 URL: https://issues.redhat.com/browse/WFLY-13633 Project: WildFly Issue Type: Bug Components: Transactions Reporter: Thomas Jenkinson Assignee: Michael Musgrove https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... This means that if Narayana encounters another resource with the same name at a later date it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020