[JBoss JIRA] (DROOLS-2236) Cover marshalling of UnaryTests
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-2236:
-------------------------------------
To coverage increased enough, after marshaling of decision tables was implemented, see:
- [^org.kie.workbench.common.dmn.backend.definition.v1_1.html]
> Cover marshalling of UnaryTests
> -------------------------------
>
> Key: DROOLS-2236
> URL: https://issues.jboss.org/browse/DROOLS-2236
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.6.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Fix For: 7.6.0.Final
>
> Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2234:
--------------------------------
No, I haven't fixed this yet. As per my other comment on a related issue, I'm not too happy about {{CENTRAL_LOCK}}, as it doesn't handle network partitions (split brain scenarios) properly...
I've been thinking to replace / complement the backups with a reconciliation protocol after the coordinator leaves, where the new coord fetches lock information from all lock holders and builds its lock table from that information. This means it would take a bit longer to serve lock requests after a coord change, but we wouldn't need to send requests from the coord to all backups.
OTOH, this doesn't solve the issue of split brain scenarios and the {{Lock}} abstraction, which is a bad abstraction to take locks away from someone (after a split heals) and allows for multiple holders of the same lock during the split...
> Unlocked locks stay locked forever
> ----------------------------------
>
> Key: JGRP-2234
> URL: https://issues.jboss.org/browse/JGRP-2234
> Project: JGroups
> Issue Type: Bug
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 4.0.10
>
> Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure.
> What we think is happening:
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2261) [DMN Designer] DND Column width is not preserved
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2261:
-----------------------------------
Summary: [DMN Designer] DND Column width is not preserved
Key: DROOLS-2261
URL: https://issues.jboss.org/browse/DROOLS-2261
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.6.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: after-reopen.png, non-saved.png
The DND Grid Columns don't preserve column width between savings.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get() throws CancellationException
by Denis Shklyaev (JIRA)
Denis Shklyaev created WFLY-9721:
------------------------------------
Summary: AsyncInvocationTask.get() throws CancellationException
Key: WFLY-9721
URL: https://issues.jboss.org/browse/WFLY-9721
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Final
Reporter: Denis Shklyaev
Priority: Optional
AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:
{{ public synchronized Object get() throws InterruptedException, ExecutionException {
for (;;) switch (status) {
case ST_RUNNING: wait(); break;
*case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
case ST_FAILED: throw new ExecutionException(failed);
case ST_DONE: return result;
default: throw Assert.impossibleSwitchCase(status);
}
}
}}
Wildfly 10.01.0 code is different:
{{ public synchronized Object get() throws InterruptedException, ExecutionException {
while (!isDone()) {
wait();
}
if (failed != null) {
throw new ExecutionException(failed);
}
return result;
}
}}
It throws InterruptedException instead as declared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-3594) Wildfly showing the war file status as Failed after restart the server
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3594:
------------------------------------------
[~daoudam] - I did not, was not able to reproduce in any way. Are you using latest master? if you do, can you please post exact steps/config and example app? ( and reopen)
> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
> Key: WFLY-3594
> URL: https://issues.jboss.org/browse/WFLY-3594
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Final
> Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
> Reporter: shaik masthan
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: restarting
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs and i am able to access the the application without any problems.
> After some time happen , again i restart the server this time war file status is deployed.
> intermittently i am viewing this weird behavior with war files w.r. t restarting the server.
> let me know any workaround or fix for this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months