November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-629) Streaming state transfer repeats set state events in highly concurrent situation

by Vladimir Blagojevic (JIRA)

Streaming state transfer repeats set state events in highly concurrent situation -------------------------------------------------------------------------------- Key: JGRP-629 URL: http://jira.jboss.com/jira/browse/JGRP-629 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5.1 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.5.2, 2.6.1, 2.7 Similar to regular state transfer streaming state transfer protocol maintains a list of state requesters. As state response is sent to requesters these entries are removed from the list. However, in highly concurrent scenarios where dozen of nodes are started and request get-and-state transfer state requesters entries in the list are filled up and as the list is iterated *multiple* state responses might be sent to state requester. This behavior is not usually noticed by users as a bug but should be fixed anyhow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
6
0 / 0

[JBoss JIRA] Created: (JGRP-626) TCP ConnectionTable threads should be started after TP threads

by Vladimir Blagojevic (JIRA)

TCP ConnectionTable threads should be started after TP threads -------------------------------------------------------------- Key: JGRP-626 URL: http://jira.jboss.com/jira/browse/JGRP-626 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5.1 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6.1, 2.7 Just like in UDP we first have to initialize and start TP threads and then threads specific to TCP connection table. Otherwise, we might receive messages in connection table that are passed to uninitialized TP protocol. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-624) connect-with-state-transfer not working when multiple clients simultaneously try to connect-with-state-transfer

by Michael Newcomb (JIRA)

connect-with-state-transfer not working when multiple clients simultaneously try to connect-with-state-transfer --------------------------------------------------------------------------------------------------------------- Key: JGRP-624 URL: http://jira.jboss.com/jira/browse/JGRP-624 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Michael Newcomb Assigned To: Bela Ban 1. have 2 members of a group connected 2. simultaneously launch 3 new members that connect with a state transfer request 3. each of the 3 new members eventually time out awaiting state transfer I was watching the log on the initially connected members (1 coordinator and 1 member) and I watched as each of the new members slowly joined (about 10s between each new view). However, on the coordinator log, I saw some GMS 'flush failure' messages. I will be re-running with all the logs on and will report back. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JGRP-623) First event in both Channel and MuxChannel should always be BLOCK and the last event should be UNBLOCK

by Vladimir Blagojevic (JIRA)

First event in both Channel and MuxChannel should always be BLOCK and the last event should be UNBLOCK ------------------------------------------------------------------------------------------------------ Key: JGRP-623 URL: http://jira.jboss.com/jira/browse/JGRP-623 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Priority: Minor Fix For: 2.6.1, 2.7 We ensure that block|unblock|view|get/setstate events are ordered did not ensure that a channel is returned into a starting state with respect to events. Therefore, Flush should always ensure that first event that channel receives should always be BLOCK and the last event should be UNBLOCK. Added this check in FlushTest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-622) Stop flush should be invoked by cluster members individually when flush coordinator leaves

by Vladimir Blagojevic (JIRA)

Stop flush should be invoked by cluster members individually when flush coordinator leaves ------------------------------------------------------------------------------------------ Key: JGRP-622 URL: http://jira.jboss.com/jira/browse/JGRP-622 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Currently when member A who is a coordinator leaves we execute flush coordinator transfer. That is member A starts flush for view V but member B completes it with stop flush. Member B, neighbor of A, receives a view V where coordinator is excluded, it takes over completion of flush. However, when B sends stop flush, then stop flush might arrive at member C *before* view V sent by A. Thus events get reordered. If each remaining member in V detects (through view) that member A left then each one of the members can complete flush individually by "pretending" that it received stop flush from A. This bug is likely to occur only with bundling disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-630) Setting option on MuxChannel (with Channel.setOpt(Channel.LOCAL, Boolean.FALSE) ) results in all MuxChannel not receiving any messages

by Vladimir Blagojevic (JIRA)

Setting option on MuxChannel (with Channel.setOpt(Channel.LOCAL,Boolean.FALSE) ) results in all MuxChannel not receiving any messages ------------------------------------------------------------------------------------------------------------------------------------- Key: JGRP-630 URL: http://jira.jboss.com/jira/browse/JGRP-630 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6.1, 2.7 If an application creates a multiplexed channel and then sets an option on that channel: Channel.setOpt(Channel.LOCAL,Boolean.FALSE) then all messages destined to all MuxChannels on top of the same regular channel will be dropped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-635) ConcurrentModificationException in FLUSH

by Robert Newson (JIRA)

ConcurrentModificationException in FLUSH ---------------------------------------- Key: JGRP-635 URL: http://jira.jboss.com/jira/browse/JGRP-635 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Robert Newson Assigned To: Bela Ban ERROR - failed sending message to null (160 bytes) java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.jgroups.protocols.pbcast.FLUSH$FlushHeader.writeTo(FLUSH.java:890) at org.jgroups.Message.writeHeader(Message.java:799) at org.jgroups.Message.writeTo(Message.java:685) at org.jgroups.protocols.TP.writeMessage(TP.java:1234) at org.jgroups.protocols.TP.send(TP.java:1199) at org.jgroups.protocols.TP.down(TP.java:963) at org.jgroups.protocols.Discovery.down(Discovery.java:351) at org.jgroups.protocols.MERGE2.down(MERGE2.java:176) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:364) at org.jgroups.protocols.FD.down(FD.java:357) at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:95) at org.jgroups.protocols.BARRIER.down(BARRIER.java:97) at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:766) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:568) at org.jgroups.protocols.UNICAST.down(UNICAST.java:437) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:317) at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:173) at org.jgroups.protocols.pbcast.GMS.down(GMS.java:838) at org.jgroups.protocols.FRAG2.down(FRAG2.java:175) at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:200) at org.jgroups.protocols.pbcast.FLUSH.onFlushCompleted(FLUSH.java:733) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:350) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:144) at org.jgroups.protocols.FRAG2.up(FRAG2.java:205) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:767) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:161) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:579) at org.jgroups.protocols.UNICAST.up(UNICAST.java:250) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:714) at org.jgroups.protocols.BARRIER.up(BARRIER.java:122) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:322) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:300) at org.jgroups.protocols.MERGE2.up(MERGE2.java:145) at org.jgroups.protocols.Discovery.up(Discovery.java:246) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1510) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1459) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) : -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
4
0 / 0

[JBoss JIRA] Updated: (JBAOP-209) Change any usage of java.rmi.MarshalledObject with JBoss Serialization's equivalent.

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-209?page=all ] Kabir Khan updated JBAOP-209: ----------------------------- Fix Version/s: 2.0.0.CR2 (was: 2.0.0.CR1) > Change any usage of java.rmi.MarshalledObject with JBoss Serialization's equivalent. > ------------------------------------------------------------------------------------ > > Key: JBAOP-209 > URL: http://jira.jboss.com/jira/browse/JBAOP-209 > Project: JBoss AOP > Issue Type: Feature Request > Affects Versions: 1.3.5 > Reporter: Bill Burke > Assigned To: Bill Burke > Priority: Minor > Fix For: 2.0.0.CR2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAOP-253) Before release, submit the jar to the Messaging team for testing

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ] Kabir Khan updated JBAOP-253: ----------------------------- Fix Version/s: 2.0.0.CR2 (was: 2.0.0.CR1) > Before release, submit the jar to the Messaging team for testing > ---------------------------------------------------------------- > > Key: JBAOP-253 > URL: http://jira.jboss.com/jira/browse/JBAOP-253 > Project: JBoss AOP > Issue Type: Task > Reporter: Ovidiu Feodorov > Assigned To: Kabir Khan > Priority: Minor > Fix For: 2.0.0.CR2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3812) TomcatDeployment should use modified WebMetaData

by Thomas Diesler (JIRA)

TomcatDeployment should use modified WebMetaData ------------------------------------------------ Key: JBAS-3812 URL: http://jira.jboss.com/jira/browse/JBAS-3812 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: JBossAS-5.0.0.Beta The Web Service Deployers modify the WebMetaData. This should then be used to deploy to Tomcat. Rewrite of the war should not be necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

6
11
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 November 2007