[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
[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
[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
[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
[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