February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to 2.8.12

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.... ] Carlo de Wolf commented on WFLY-9730: ------------------------------------- This needs to be addressed before releasing WF 12. Should we do a build, release & PR of 2.8.11-5-g038b471e2 as opposed to waiting for 2.8.12? > Upgrade FasterXML Jackson to 2.8.12 > ----------------------------------- > > Key: WFLY-9730 > URL: https://issues.jboss.org/browse/WFLY-9730 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Ivo Studensky > Assignee: Jason Greene > Priority: Blocker > Labels: downstream_dependency > Fix For: 12.0.0.Final > > > Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to 2.8.12

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-9730: -------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.Alpha1) > Upgrade FasterXML Jackson to 2.8.12 > ----------------------------------- > > Key: WFLY-9730 > URL: https://issues.jboss.org/browse/WFLY-9730 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Ivo Studensky > Assignee: Jason Greene > Priority: Blocker > Labels: downstream_dependency > Fix For: 12.0.0.Final > > > Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to 2.8.12

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-9730: -------------------------------- Priority: Blocker (was: Major) > Upgrade FasterXML Jackson to 2.8.12 > ----------------------------------- > > Key: WFLY-9730 > URL: https://issues.jboss.org/browse/WFLY-9730 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Ivo Studensky > Assignee: Jason Greene > Priority: Blocker > Labels: downstream_dependency > Fix For: 12.0.0.Alpha1 > > > Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to 2.8.12

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-9730: -------------------------------- Fix Version/s: 12.0.0.Alpha1 > Upgrade FasterXML Jackson to 2.8.12 > ----------------------------------- > > Key: WFLY-9730 > URL: https://issues.jboss.org/browse/WFLY-9730 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Ivo Studensky > Assignee: Jason Greene > Priority: Blocker > Labels: downstream_dependency > Fix For: 12.0.0.Alpha1 > > > Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9536) BeanDeploymentArchiveImpl should implement BeanDeploymentArchive.getKnownClasses()

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-9536?page=com.atlassian.jira.plugin.... ] Matej Novotny updated WFLY-9536: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10816 > BeanDeploymentArchiveImpl should implement BeanDeploymentArchive.getKnownClasses() > ---------------------------------------------------------------------------------- > > Key: WFLY-9536 > URL: https://issues.jboss.org/browse/WFLY-9536 > Project: WildFly > Issue Type: Task > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Matej Novotny > > This would allow Weld to get all the types found in an _implicit_ bean archive, see also WELD-2045. > Requires Weld 3.0 API. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2184) UX design DRD logic table actions

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-2184: -------------------------------- Attachment: (was: kebab-dmn.png) > UX design DRD logic table actions > --------------------------------- > > Key: DROOLS-2184 > URL: https://issues.jboss.org/browse/DROOLS-2184 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam > Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png, kebab-where.png > > > Use case description:   As a business user (Citizen Developer…), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.    > Verification Conditions > * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2249) CENTRAL_LOCK2: reconciliation protocolon coord change

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2249?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2249: --------------------------- Description: Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly. This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments). Comment from 2234: Clients need to have the following information: * Locks they acquired * Pending lock requests; locks which they want to acquire but for which they haven't yet received a LOCK_GRANTED response * Pending lock release requests; lock that have been released, but for which no RELEASE_LOCK_OK response has been received * Ditto for conditions, but we'll tackle them in a second stage The reconciliation protocol queues all new requests on the coord and asks all members for their lock information. Once the coord has received this information from all members, it applies this and then drains the queue of pending requests. It is important that the requests are ordered per member, ie. a release(L) cannot come before a lock(L). Since {{CENTRAL_LOCK}} allows for multiple members to hold the same lock in a split brain scenario, we need to think about how to handle merging where the coord detects that multiple members hold the same lock... was: Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly. This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments). > CENTRAL_LOCK2: reconciliation protocolon coord change > ----------------------------------------------------- > > Key: JGRP-2249 > URL: https://issues.jboss.org/browse/JGRP-2249 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.11 > > > Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly. > This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments). > Comment from 2234: > Clients need to have the following information: > * Locks they acquired > * Pending lock requests; locks which they want to acquire but for which they haven't yet received a LOCK_GRANTED response > * Pending lock release requests; lock that have been released, but for which no RELEASE_LOCK_OK response has been received > * Ditto for conditions, but we'll tackle them in a second stage > The reconciliation protocol queues all new requests on the coord and asks all members for their lock information. Once the coord has received this information from all members, it applies this and then drains the queue of pending requests. > It is important that the requests are ordered per member, ie. a release(L) cannot come before a lock(L). > Since {{CENTRAL_LOCK}} allows for multiple members to hold the same lock in a split brain scenario, we need to think about how to handle merging where the coord detects that multiple members hold the same lock... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[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 edited comment on JGRP-2234 at 2/6/18 7:38 AM: -------------------------------------------------------- Perhaps it's better to implement the simple change I described above (acking and possibly resending release requests) in this JIRA and create a new JIRA for the reconciliation protocol... This would be {{CENTRAL_LOCK2}}. Created https://issues.jboss.org/browse/JGRP-2249 to keep track of this was (Author: belaban): Perhaps it's better to implement the simple change I described above (acking and possibly resending release requests) in this JIRA and create a new JIRA for the reconciliation protocol... This would be {{CENTRAL_LOCK2}}. > 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.11 > > 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 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

1
0
0 / 0

[JBoss JIRA] (JGRP-2249) CENTRAL_LOCK2: reconciliation protocolon coord change

by Bela Ban (JIRA)

Bela Ban created JGRP-2249: ------------------------------ Summary: CENTRAL_LOCK2: reconciliation protocolon coord change Key: JGRP-2249 URL: https://issues.jboss.org/browse/JGRP-2249 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.11 Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly. This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[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: -------------------------------- Perhaps it's better to implement the simple change I described above (acking and possibly resending release requests) in this JIRA and create a new JIRA for the reconciliation protocol... This would be {{CENTRAL_LOCK2}}. > 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.11 > > 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 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

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 February 2018