February 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBXB-173) use the same JBossXBTestDelegate for the whole testsuite and don't fork

by Alexey Loubyansky (JIRA)

use the same JBossXBTestDelegate for the whole testsuite and don't fork ----------------------------------------------------------------------- Key: JBXB-173 URL: https://jira.jboss.org/jira/browse/JBXB-173 Project: JBoss XML Binding (JBossXB) Issue Type: Task Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossXB-2.0.1.CR1 There are JBossXBTestDelegate classes in different packages that are mostly the same. This causes static initialization issues (with URL handler factories) and is the reason for forking one JVM thread per test which is incredibly slow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-895) Java web start (JNLP) demos: sign JARs via ANT

by Bela Ban (JIRA)

Java web start (JNLP) demos: sign JARs via ANT ---------------------------------------------- Key: JGRP-895 URL: https://jira.jboss.org/jira/browse/JGRP-895 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.8 This is in JGroupsWebsite/jnlp. We currentlly have a signed replcachedemo.jar in CVS, but this needs to be changed: - Generate jgroups-all in JGroups - Copy jgroups-all, commons-logging and log4j JARs to jnlp dir - Create temp keystore (makeKeystore target ?) - KeySign Ant task to sign *all* JARs - Remove keystore - This should be done only when not up-to-date -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
1
0 / 0

[JBoss JIRA] Updated: (JGRP-129) Logical addresses

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-129?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-129: -------------------------- Description: The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on - Network Address Translation: the sender's address might get changed by the NAT DESIGN: - A logical address consists of - a user-given (or generated) name, e.g. "X". This name stays with the address from channel creation to channel close - a UUID. This is created on channel connect, deleted on channel disconnect and re-created on channel connect. This is used for equals() and hashCode() of the logical address. Since it is re-created on every connect(), it will prevent reincarnation issues. UUIDs are guaranteed to be unique over time for a given host. This is better than using address:port, because port is not guaranteed to be unique over time, especially when we use bind_port - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). was: The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on - Network Address Translation: the sender's address might get changed by the NAT DESIGN: - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). > Logical addresses > ----------------- > > Key: JGRP-129 > URL: https://jira.jboss.org/jira/browse/JGRP-129 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.8 > > > The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: > - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper > - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC > - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on > - Network Address Translation: the sender's address might get changed by the NAT > DESIGN: > - A logical address consists of > - a user-given (or generated) name, e.g. "X". This name stays with the address from channel creation > to channel close > - a UUID. This is created on channel connect, deleted on channel disconnect and re-created on channel > connect. This is used for equals() and hashCode() of the logical address. Since it is re-created on > every connect(), it will prevent reincarnation issues. UUIDs are guaranteed to be unique over time for > a given host. This is better than using address:port, because port is not guaranteed to be unique over > time, especially when we use bind_port > - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. > - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). > - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-858) Generic flags per message

by Bela Ban (JIRA)

Generic flags per message ------------------------- Key: JGRP-858 URL: https://jira.jboss.org/jira/browse/JGRP-858 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Investigate whether we can add generic flags to a message. Currently, we have a byte field and a few predefined flags (OOB, LOW_PRIO, HIGH_PRIO) in each message, but that means we only have a limited number of flags available to us. Goal: find a way to add an infinite number of flags to a message, possibly even used defined flags. EnumSet ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-888) concurrent modification exception in FD_SIMPLE

by Sam Hsu (JIRA)

concurrent modification exception in FD_SIMPLE ---------------------------------------------- Key: JGRP-888 URL: https://jira.jboss.org/jira/browse/JGRP-888 Project: JGroups Issue Type: Bug Affects Versions: 2.6.7 Reporter: Sam Hsu Assignee: Bela Ban Priority: Minor iterators in down() and printCounters() need synchronized(counters) to avoid exception -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-891) ConcurrentModificationException during JBoss AS 5.0.0.GA startup

by Paul Ferraro (JIRA)

ConcurrentModificationException during JBoss AS 5.0.0.GA startup ---------------------------------------------------------------- Key: JGRP-891 URL: https://jira.jboss.org/jira/browse/JGRP-891 Project: JGroups Issue Type: Bug Affects Versions: 2.6.7 Reporter: Paul Ferraro Assignee: Bela Ban 17:31:01,970 ERROR [UDP] failed handling incoming message java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:365) at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376) at java.util.AbstractCollection.containsAll(AbstractCollection.java:285) at java.util.AbstractSet.equals(AbstractSet.java:76) at org.jgroups.protocols.pbcast.STABLE.allVotesReceived(STABLE.java:428) at org.jgroups.protocols.pbcast.STABLE.addVote(STABLE.java:423) at org.jgroups.protocols.pbcast.STABLE.handleStableMessage(STABLE.java:554) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:238) at org.jgroups.protocols.UNICAST.up(UNICAST.java:299) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:842) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:705) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:284) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:308) at org.jgroups.protocols.MERGE2.up(MERGE2.java:144) at org.jgroups.protocols.Discovery.up(Discovery.java:263) at org.jgroups.protocols.PING.up(PING.java:270) at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2319) at org.jgroups.protocols.TP.passMessageUp(TP.java:1253) at org.jgroups.protocols.TP.access$100(TP.java:49) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1830) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1809) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Here are the problematic lines in STABLE.java: 427: private boolean allVotesReceived(Set<Address> votes) { 428: return votes.equals(mbrs); // compares identity, size and element-wise (if needed) 429: } Internally, the Set.equals(...) method will iterate over the mbrs set. The concurrent update is coming from the following code in STABLE.java: 330: private void handleViewChange(View v) { 331: Vector<Address> tmp=v.getMembers(); 332: synchronized(mbrs) { 333: mbrs.clear(); 334: mbrs.addAll(tmp); 335: } There are several ways fix this, including, but not limited to: * Wrap line 428 in a synchronized(mbrs) block * Make mbrs volatile instead of final, and create a new LinkedHashSet in handleViewChange(...) i.e. Replace 332-335 with: mbrs = new LinkedHashSet<Address>(tmp); * Make mbrs a CopyOnWriteArraySet<Address> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-896) GMS: ConcurrentModificationException in AckCollector.handleView()

by John Doe (JIRA)

GMS: ConcurrentModificationException in AckCollector.handleView() ----------------------------------------------------------------- Key: JGRP-896 URL: https://jira.jboss.org/jira/browse/JGRP-896 Project: JGroups Issue Type: Bug Affects Versions: 2.6.5 Reporter: John Doe Assignee: Bela Ban We encountered the following CME exception on one of our production environment: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:860) at java.util.AbstractCollection.retainAll(AbstractCollection.java:393) at org.jgroups.util.AckCollector.handleView(AckCollector.java:85) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:479) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:460) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:711) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.up(UNICAST.java:299) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:861) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:693) at org.jgroups.protocols.BARRIER.up(BARRIER.java:136) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:308) at org.jgroups.protocols.MERGE2.up(MERGE2.java:144) at org.jgroups.protocols.Discovery.up(Discovery.java:263) at org.jgroups.protocols.TP.passMessageUp(TP.java:1275) at org.jgroups.protocols.TP.access$100(TP.java:49) at org.jgroups.protocols.TP$1.run(TP.java:1178) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-6457) Update EJB3 to 1.1.0

by Jason T. Greene (JIRA)

Update EJB3 to 1.1.0 -------------------- Key: JBAS-6457 URL: https://jira.jboss.org/jira/browse/JBAS-6457 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assignee: Carlo de Wolf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

2
1
0 / 0

[JBoss JIRA] Deleted: (JBAS-6020) Upgrade EJB3 to its final version for AS5

by Jason T. Greene (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-6020?page=com.atlassian.jira.plug... ] Jason T. Greene deleted JBAS-6020: ---------------------------------- > Upgrade EJB3 to its final version for AS5 > ----------------------------------------- > > Key: JBAS-6020 > URL: https://jira.jboss.org/jira/browse/JBAS-6020 > Project: JBoss Application Server > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Dimitris Andreadis > Assignee: Carlo de Wolf > Priority: Critical > > Whichever will be the final version for AS5 GA and passes EJB3's own testsuite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBAS-6112) Upgrade jpa-deployers to 1.0.0.GA

by Jason T. Greene (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-6112?page=com.atlassian.jira.plug... ] Jason T. Greene deleted JBAS-6112: ---------------------------------- > Upgrade jpa-deployers to 1.0.0.GA > --------------------------------- > > Key: JBAS-6112 > URL: https://jira.jboss.org/jira/browse/JBAS-6112 > Project: JBoss Application Server > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assignee: Carlo de Wolf > Priority: Critical > > Update to pick up JBAS-6111 fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 5 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 2009