February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda closed WFCORE-3545. ------------------------------ Resolution: Done > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda reopened WFCORE-3545: -------------------------------- > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Erich Duda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Erich Duda commented on WFCORE-3545: ------------------------------------ This issue has wrong state. It should have status NEW. I will correct it. > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ] Marek Kopecký commented on WFCORE-3545: --------------------------------------- Test for down key is [here|https://github.com/wildfly/wildfly-core/blob/master/testsuite/standa...], needs to be uncommented after this issue will be fixed. > Composed keys don't have to be recognized by CLI > ------------------------------------------------ > > Key: WFCORE-3545 > URL: https://issues.jboss.org/browse/WFCORE-3545 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha6 > Reporter: Erich Duda > Assignee: Jean-Francois Denise > > Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant. > However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream. > If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s). > The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2288) Guided Rule Editor: Not possible to reopen FROM ACCUMULATE

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2288?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-2288: --------------------------------- Description: Create the rule in the image and when you reopen the rule an error about "FROM ACCUMULATE" appears. !GuidedComplex.png|thumbnail! > Guided Rule Editor: Not possible to reopen FROM ACCUMULATE > ---------------------------------------------------------- > > Key: DROOLS-2288 > URL: https://issues.jboss.org/browse/DROOLS-2288 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Michael Anstis > Attachments: GuidedComplex.png > > > Create the rule in the image and when you reopen the rule an error about "FROM ACCUMULATE" appears. > !GuidedComplex.png|thumbnail! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2288) Guided Rule Editor: Not possible to reopen FROM ACCUMULATE

by Toni Rikkola (JIRA)

Toni Rikkola created DROOLS-2288: ------------------------------------ Summary: Guided Rule Editor: Not possible to reopen FROM ACCUMULATE Key: DROOLS-2288 URL: https://issues.jboss.org/browse/DROOLS-2288 Project: Drools Issue Type: Bug Components: Guided Rule Editor Reporter: Toni Rikkola Assignee: Michael Anstis Attachments: GuidedComplex.png -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2288) Guided Rule Editor: Not possible to reopen FROM ACCUMULATE

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2288?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-2288: --------------------------------- Attachment: GuidedComplex.png > Guided Rule Editor: Not possible to reopen FROM ACCUMULATE > ---------------------------------------------------------- > > Key: DROOLS-2288 > URL: https://issues.jboss.org/browse/DROOLS-2288 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Michael Anstis > Attachments: GuidedComplex.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2228) ASYM_ENCRYPT: test with encrypt_entire_msg=true

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2228?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2228: --------------------------- Fix Version/s: 4.0.11 (was: 4.0.10) > ASYM_ENCRYPT: test with encrypt_entire_msg=true > ----------------------------------------------- > > Key: JGRP-2228 > URL: https://issues.jboss.org/browse/JGRP-2228 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.11 > > Attachments: asym-encrypt.xml, asym-encrypt.xml > > > * Start a few nodes with {{ASYM_ENCRYPT}} and {{encrypt_entire_msg}} set to {{true}} > * Kill and restart a member > * Apparently, restarting is not possible, as the new member won't be able to join the cluster > -> Verify this is true and - if yes - fix it -- 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 updated JGRP-2234: --------------------------- Fix Version/s: 4.0.11 (was: 4.0.10) > 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 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

1
0
0 / 0

[JBoss JIRA] (JGRP-2235) ConcurrentModificationException when resend pending lock requests

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2235?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2235: --------------------------- Fix Version/s: 4.0.11 (was: 4.0.10) > ConcurrentModificationException when resend pending lock requests > ----------------------------------------------------------------- > > Key: JGRP-2235 > URL: https://issues.jboss.org/browse/JGRP-2235 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.11 > > > While testing JGRP-2234 we saw a ConcurrentModificationException in the locking protocol in some (rare) situations: > {noformat} > 09:46:42.856 [jgroups-7,TEST,B] ERROR org.jgroups.protocols.pbcast.GMS - JGRP000027: failed passing message up > java.util.ConcurrentModificationException: null > at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1630) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_151] > at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:1.8.0_151] > at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:1.8.0_151] > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_151] > at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:1.8.0_151] > at org.jgroups.protocols.Locking$ClientLockTable.lambda$resendPendingLockRequests$3(Locking.java:1085) ~[classes/:?] > at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707) ~[?:1.8.0_151] > at org.jgroups.protocols.Locking$ClientLockTable.resendPendingLockRequests(Locking.java:1084) ~[classes/:?] > at org.jgroups.protocols.CENTRAL_LOCK.handleView(CENTRAL_LOCK.java:147) ~[classes/:?] > at org.jgroups.protocols.Locking.up(Locking.java:218) ~[classes/:?] > at org.jgroups.protocols.FRAG2.up(FRAG2.java:163) ~[classes/:?] > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:702) ~[classes/:?] > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) ~[classes/:?] > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) ~[classes/:?] > at org.jgroups.stack.Protocol.up(Protocol.java:364) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) [classes/:?] > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) [classes/:?] > at org.jgroups.stack.Protocol.up(Protocol.java:372) [classes/:?] > at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) [classes/:?] > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) [classes/:?] > at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) [classes/:?] > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) [classes/:?] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_151] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_151] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151] > {noformat} -- 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