August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4395) [DMN Designer] Validation fails for included models

by Edson Tirelli (Jira)

[ https://issues.jboss.org/browse/DROOLS-4395?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-4395: ------------------------------------- Assignee: Guilherme Gomes (was: Michael Anstis) > [DMN Designer] Validation fails for included models > --------------------------------------------------- > > Key: DROOLS-4395 > URL: https://issues.jboss.org/browse/DROOLS-4395 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.25.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > Attachments: Screenshot from 2019-08-02 14-01-32.png, error.log > > > The attached screenshot shows an error coming from a dmn file that has a imported another dmn model. All dmn models with imported other models (dmn or pmml) throws an error during validation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4245) [DMN Designer] Documentation - Enhance presentation

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4245?page=com.atlassian.jira.plugi... ] Elizabeth Clayton commented on DROOLS-4245: ------------------------------------------- [~bdellasc] kk, good to know thanks! Can we mark this jira as Resolved then? > [DMN Designer] Documentation - Enhance presentation > --------------------------------------------------- > > Key: DROOLS-4245 > URL: https://issues.jboss.org/browse/DROOLS-4245 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Brian Dellascio > Priority: Major > Labels: UX, UXTeam, VisualDesign, drools-tools > Attachments: RedHat_KIE_logo.eps, RedHat_KIE_logo.png, RedHat_KIE_logo.svg, doc.pdf, new_doc.pdf > > > Enhance styles and presentation of the Documentation output. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2366) Log UDP network interface and port range

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/JGRP-2366?page=com.atlassian.jira.plugin.... ] Diego Lovison moved ISPN-10467 to JGRP-2366: -------------------------------------------- Project: JGroups (was: Infinispan) Key: JGRP-2366 (was: ISPN-10467) Workflow: GIT Pull Request workflow (was: GIT Pull Request with Triage workflow) > Log UDP network interface and port range > ---------------------------------------- > > Key: JGRP-2366 > URL: https://issues.jboss.org/browse/JGRP-2366 > Project: JGroups > Issue Type: Enhancement > Reporter: Diego Lovison > Priority: Minor > > I would like to use tshark. > With this PR the log will have what are the values that I should use. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2318) KUBE_PING: test with RBAC

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2318?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2318. ---------------------------- Resolution: Done https://github.com/jgroups-extras/jgroups-kubernetes works (by adding the correct permissions to fetch all pods' addresses from Kubernetes) > KUBE_PING: test with RBAC > ------------------------- > > Key: JGRP-2318 > URL: https://issues.jboss.org/browse/JGRP-2318 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.3 > > > Test if KUBE_PING still works with the latest minikube/RBAC combo -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2320. ---------------------------- Resolution: Done > FILE_PING.findMembers() optimizations > ------------------------------------- > > Key: JGRP-2320 > URL: https://issues.jboss.org/browse/JGRP-2320 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.16, 4.0.15 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.3 > > > Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified. > 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter. > To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null. > 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7297) It is not possible to explode and browse deployments within deployment

by Michal Petrov (Jira)

[ https://issues.jboss.org/browse/WFLY-7297?page=com.atlassian.jira.plugin.... ] Michal Petrov commented on WFLY-7297: ------------------------------------- [~harald.pehl], as I wrote above "undeploy, explode, deploy" doesn't work in a batch, is there some way to delay the last operation? Otherwise the best we can do is just the first two and then the user has to enable the deployment manually. > It is not possible to explode and browse deployments within deployment > ---------------------------------------------------------------------- > > Key: WFLY-7297 > URL: https://issues.jboss.org/browse/WFLY-7297 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 11.0.0.Alpha1 > Reporter: Jan Štefl > Assignee: Harald Pehl > Priority: Major > Attachments: jboss-kitchensink-ear.ear > > > It is possible to explode and browse content of top level deployment but there is no possibility for such operation with deployment. > Attaching test deployent for experiments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on WFLY-12317: ----------------------------------------- We are going with the fix for JVM restart. > Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed > --------------------------------------------------------------------------------------------------- > > Key: WFLY-12317 > URL: https://issues.jboss.org/browse/WFLY-12317 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 17.0.0.Final > Reporter: Ivan Straka > Assignee: Michael Musgrove > Priority: Critical > Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log > > > We have following test scenario (3 servers) that fails: > # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property) > # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped > # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded > # server3 is running > # client call an EJB bean (where a transaction is started) on the server1 > # the EJB sends JMS message to the server3 (broker) > # the EJB enlists dummy xa resource > # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked > # we move server1 object store directory to the server2 > # server2 is started > # the server2 is expected to rollback whole transaction > Transaction is unfinished because server2 has not performed rollback. > {code:java} > prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE! > java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1 > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792) > at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565) > {code} > In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X. > I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback. > See node_name > Server1: > {code:java} > 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed > {code} > {code:java} > 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47 > {code} > Server2: > > {code:java} > 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed > {code} > {code:java} > 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd > 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN > {code} > *When does the scenario pass* > When I run the TS with > {code:java} > -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid > {code} > the test passes (old and new node-identifier on both servers are same) > When step 3 slightly differs: > When restart is performed instead of reload op. > Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid > *tldr;* > The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2320: -------------------------------- Re 1: the case where {{members != null}} is very seldom and occurs only once if a given member's data is missing. I therefore don't want to change the logic with the risk of introducing bugs. Re 2: changed that, thanks! > FILE_PING.findMembers() optimizations > ------------------------------------- > > Key: JGRP-2320 > URL: https://issues.jboss.org/browse/JGRP-2320 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.16, 4.0.15 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.3 > > > Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified. > 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter. > To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null. > 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12358) Component upgrade of Narayana to 5.9.6.Final

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-12358?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka closed WFLY-12358. ----------------------------------- Resolution: Duplicate Issue > Component upgrade of Narayana to 5.9.6.Final > -------------------------------------------- > > Key: WFLY-12358 > URL: https://issues.jboss.org/browse/WFLY-12358 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 17.0.1.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12358) Component upgrade of Narayana to 5.9.6.Final

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-12358?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on WFLY-12358: ----------------------------------------- Duplicated to issue WFLY-12341 > Component upgrade of Narayana to 5.9.6.Final > -------------------------------------------- > > Key: WFLY-12358 > URL: https://issues.jboss.org/browse/WFLY-12358 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 17.0.1.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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 August 2019