March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1802: --------------------------- Fix Version/s: 3.5 > OverlappingUnicastMergeTest > --------------------------- > > Key: JGRP-1802 > URL: https://issues.jboss.org/browse/JGRP-1802 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Solaris, RHEL > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13, 3.5 > > > OverlappingUnicastMergeTest does the following: > - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed > - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received > - inject some new view into the channels which represents a view configuration which should be recovered from > - send messages to the channels and check that the messages are received, despite the injected view > OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from MODIFIED to ON_QA > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1802: ------------------------------------------- In the test setup, it would also be safer to use Util.waitUntilAllChannelHaveSameSize() rather than an immediate check on view formation. > OverlappingUnicastMergeTest > --------------------------- > > Key: JGRP-1802 > URL: https://issues.jboss.org/browse/JGRP-1802 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Solaris, RHEL > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > OverlappingUnicastMergeTest does the following: > - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed > - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received > - inject some new view into the channels which represents a view configuration which should be recovered from > - send messages to the channels and check that the messages are received, despite the injected view > OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1802: ------------------------------------------- Looking over the code in checkReceivedMessages, it seems there is a mixup in which receivers are used to check message arrival. In the setup for the test, you define three receivers ra, rb, rc. But in checkReceivedMessages(), you send the messages and then create three receivers which are used to check message receipt: {noformat} private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception { ra.clear(); rb.clear(); rc.clear(); // 1. send unicast messages Set<Address> mbrs=new HashSet<Address>(channels.length); for(JChannel ch: channels) mbrs.add(ch.getAddress()); for(JChannel ch: channels) { Address addr=ch.getAddress(); for(Address dest: mbrs) { for(int i=1; i <= num_msgs; i++) { ch.send(dest, "unicast msg #" + i + " from " + addr); } } } int total_msgs=num_msgs * channels.length; MyReceiver[] receivers=new MyReceiver[channels.length]; for(int i=0; i < channels.length; i++) receivers[i]=(MyReceiver)channels[i].getReceiver(); checkReceivedMessages(total_msgs, receivers); } {noformat} Isn't it possible that messages will be received by channels before these receivers are installed? Would this not be safer? {noformat} private void sendAndCheckMessages(int num_msgs, JChannel ... channels) throws Exception { ra.clear(); rb.clear(); rc.clear(); // send unicast messages Set<Address> mbrs=new HashSet<Address>(channels.length); for(JChannel ch: channels) mbrs.add(ch.getAddress()); for(JChannel ch: channels) { Address addr=ch.getAddress(); for(Address dest: mbrs) { for(int i=1; i <= num_msgs; i++) { ch.send(dest, "unicast msg #" + i + " from " + addr); } } } // check unicast message arrival int total_msgs=num_msgs * channels.length; checkReceivedMessages(total_msgs, ra,rb,rc); } {noformat} > OverlappingUnicastMergeTest > --------------------------- > > Key: JGRP-1802 > URL: https://issues.jboss.org/browse/JGRP-1802 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Solaris, RHEL > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > OverlappingUnicastMergeTest does the following: > - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed > - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received > - inject some new view into the channels which represents a view configuration which should be recovered from > - send messages to the channels and check that the messages are received, despite the injected view > OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1148) IronJacamar 1.0.24.Final

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1148?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1148. ------------------------------------ Resolution: Done > IronJacamar 1.0.24.Final > ------------------------ > > Key: JBJCA-1148 > URL: https://issues.jboss.org/browse/JBJCA-1148 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.24.Final > > > Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1148) IronJacamar 1.0.24.Final

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1148: -------------------------------------- Summary: IronJacamar 1.0.24.Final Key: JBJCA-1148 URL: https://issues.jboss.org/browse/JBJCA-1148 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.24.Final Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1138) TransactionSynchronizer leaks memory and causes deadlocks in jacorb

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1138?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1138: ----------------------------------- Fix Version/s: (was: 1.0.24.Final) Priority: Major (was: Blocker) > TransactionSynchronizer leaks memory and causes deadlocks in jacorb > ------------------------------------------------------------------- > > Key: JBJCA-1138 > URL: https://issues.jboss.org/browse/JBJCA-1138 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.23.Final > Reporter: Andrey Smirnov > Assignee: Jesper Pedersen > > Seems like TransactionSynchronizer has been rolled back to state it was in August. I think this was caused by little typo in commit 469b4c303dd0d5c39f3476a5972556d8b9537b44 > 296: Record record = records.get(tx); > But 'records' map uses TransactionKey as key and above line should be written as > 296:TransactionKey key = new TransactionKey(tx); > 297: Record record = records.get(key); > I've checked 1.0.22 containing applied fix and mem-leaks and deadlocks are all gone -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created JGRP-1802: ----------------------------------------- Summary: OverlappingUnicastMergeTest Key: JGRP-1802 URL: https://issues.jboss.org/browse/JGRP-1802 Project: JGroups Issue Type: Bug Affects Versions: 3.2.13 Environment: Solaris, RHEL Reporter: Richard Achmatowicz Assignee: Bela Ban Fix For: 3.2.13 OverlappingUnicastMergeTest does the following: - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received - inject some new view into the channels which represents a view configuration which should be recovered from - send messages to the channels and check that the messages are received, despite the injected view OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1802: ------------------------------------------- Here are links to some of the example failures: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-JGro... > OverlappingUnicastMergeTest > --------------------------- > > Key: JGRP-1802 > URL: https://issues.jboss.org/browse/JGRP-1802 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Solaris, RHEL > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > OverlappingUnicastMergeTest does the following: > - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed > - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received > - inject some new view into the channels which represents a view configuration which should be recovered from > - send messages to the channels and check that the messages are received, despite the injected view > OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3053) BootstrapImpl#bootstrap result is inherently racy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3053: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1071934 > BootstrapImpl#bootstrap result is inherently racy > ------------------------------------------------- > > Key: WFLY-3053 > URL: https://issues.jboss.org/browse/WFLY-3053 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: David Lloyd > Assignee: Jason Greene > Fix For: 8.0.1.Final > > > The boostrap code presently installs a stability monitor and awaits stability before returning. It then probes the state of the root service. There is a window of time in which the root service may be stopped or removed, resulting in big exception traces being logged. To atomically get the result of the operation, the service container must somehow be frozen until the root service is completely read. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 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 March 2014