August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-269) add method to register at jmx with any objectname

by Ivan Martinez (JIRA)

add method to register at jmx with any objectname ------------------------------------------------- Key: JGRP-269 URL: http://jira.jboss.com/jira/browse/JGRP-269 Project: JGroups Issue Type: Patch Environment: based on current CVS Reporter: Ivan Martinez Assigned To: Bela Ban Priority: Optional Attachments: jgroups_jmx_register.patch currently the JMX registration only permit to specidy the domain, this patch split the method and now is possible to register the channel with any ObjectName -- 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

19 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-730) Eviction policies do not always adhere to maxNodes when using optimistic locking

by Manik Surtani (JIRA)

Eviction policies do not always adhere to maxNodes when using optimistic locking -------------------------------------------------------------------------------- Key: JBCACHE-730 URL: http://jira.jboss.com/jira/browse/JBCACHE-730 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Ben Wang Fix For: 1.4.0.SP1 See OptimisticEvictionTest.testMultEvictionOccurences() -- 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

19 years, 11 months

1
4
0 / 0

[JBoss JIRA] Closed: (JBCACHE-665) Concurrent modification exception when eviction thread attempts to access workspace with opt locking

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-665?page=all ] Manik Surtani closed JBCACHE-665. --------------------------------- Resolution: Done > Concurrent modification exception when eviction thread attempts to access workspace with opt locking > ---------------------------------------------------------------------------------------------------- > > Key: JBCACHE-665 > URL: http://jira.jboss.com/jira/browse/JBCACHE-665 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.4.0 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: 1.4.0.SP1, 1.3.0.SP3 > > Time Spent: 1 day, 3 hours > Remaining Estimate: 0 minutes > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-665) Concurrent modification exception when eviction thread attempts to access workspace with opt locking

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-665?page=all ] Manik Surtani reopened JBCACHE-665: ----------------------------------- DOES apply to 1.4.0 as well! Only, not as frequent/apparent. Much more apparent if using multi cpu/core systems. > Concurrent modification exception when eviction thread attempts to access workspace with opt locking > ---------------------------------------------------------------------------------------------------- > > Key: JBCACHE-665 > URL: http://jira.jboss.com/jira/browse/JBCACHE-665 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.4.0 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: 1.3.0.SP3, 1.4.0.SP1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-665) Concurrent modification exception when eviction thread attempts to access workspace with opt locking

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-665?page=all ] Manik Surtani updated JBCACHE-665: ---------------------------------- Fix Version/s: 1.4.0.SP1 Affects Version/s: 1.4.0 > Concurrent modification exception when eviction thread attempts to access workspace with opt locking > ---------------------------------------------------------------------------------------------------- > > Key: JBCACHE-665 > URL: http://jira.jboss.com/jira/browse/JBCACHE-665 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.4.0 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: 1.3.0.SP3, 1.4.0.SP1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-1489) MessageListener does not invoke ExceptionListener on error

by Sumedh inamdar (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1489?page=comments#action_12340911 ] Sumedh inamdar commented on JBAS-1489: -------------------------------------- I am getting this problem in 4.0.2 as well. :( I am using an MDB as a queue listener. I could not yet find out the exact use case of the error. Stack trace follows... 17:42:37,487 WARN [Connection] Connection failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) at org.jboss.mq.Connection$PingTask.run(Connection.java:1323) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.IOException: ping timeout. ... 3 more 17:43:37,487 WARN [Connection] Connection failure, use javax.jms.Connection.set ExceptionListener() to handle this error and reconnect org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOE xception: ping timeout.) at org.jboss.mq.Connection$PingTask.run(Connection.java:1323) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.IOException: ping timeout. ... 3 more --------------- Thank you, Sumedh > MessageListener does not invoke ExceptionListener on error > ---------------------------------------------------------- > > Key: JBAS-1489 > URL: http://jira.jboss.com/jira/browse/JBAS-1489 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final, JBossAS-4.0.1 Final > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.0.2RC1 > > > If SpyMessageConsumer detects an error on the MessageListener thread > it should invoke the ExceptionListener. > Also, to avoid potential deadlocks with exceptions detected on the MessageListener > thread, a new thread should be started to invoke the ExceptionListener. > Otherwise the ExceptionListener will not be able to close the consumer. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-260) Two subgroups don't merge when one of the hosts in TCPPING(intial_hosts=...) list is not accessible

by Tomasz Skutnik (JIRA)

Two subgroups don't merge when one of the hosts in TCPPING(intial_hosts=...) list is not accessible --------------------------------------------------------------------------------------------------- Key: JGRP-260 URL: http://jira.jboss.com/jira/browse/JGRP-260 Project: JGroups Issue Type: Bug Affects Versions: 2.2.9.2 Environment: Debian GNU/Linux 2.4.27, JDK 1.5.0_05 Reporter: Tomasz Skutnik Assigned To: Bela Ban Attachments: Test1.java When I run client program (see attachment) with following command: - on host h1: $ java -cp \ jgroups-all-2.2.9.2.jar:concurrent.jar:commons-logging-1.1.jar:\ classes test.Test1 "h1" "h1[7800],h3[7800]" - on host h2: $ java -cp \ jgroups-all-2.2.9.2.jar:concurrent.jar:commons-logging-1.1.jar:\ classes test.Test1 "h2" "h1[7800],h3[7800]" And host "h3" is known (listed in /etc/hosts) but physically turned off both hosts (h1 and h2) create two disjoint groups instead of one merged group. And on host "h2" following warnings/errors are logged: 2006-07-11 08:56:07 org.jgroups.protocols.pbcast.CoordGmsImpl$MergeTask run WARNING: merge responses from subgroup coordinators <= 1 ([sender=172.16.195.131:7800, view=[172.16.195.131:7800|0] [172.16.195.131:7800], digest=172.16.195.131:7800: [0 : 5]]). Cancelling merge 2006-07-11 08:56:52 org.jgroups.protocols.pbcast.CoordGmsImpl$MergeTask run WARNING: merge responses from subgroup coordinators <= 1 ([sender=172.16.195.131:7800, view=[172.16.195.131:7800|0] [172.16.195.131:7800], digest=172.16.195.131:7800: [0 : 7]]). Cancelling merge 2006-07-11 08:57:26 org.jgroups.protocols.pbcast.CoordGmsImpl handleMergeResponse SEVERE: this.merge_id ([172.16.195.131:7800|1152601002343]) is different from merge_id ([172.16.195.131:7800|1152600957961]) 2006-07-11 08:58:24 org.jgroups.protocols.pbcast.CoordGmsImpl$MergeTask run WARNING: merge responses from subgroup coordinators <= 1 ([]). Cancelling merge 2006-07-11 08:58:24 org.jgroups.protocols.pbcast.CoordGmsImpl sendMergeCancelledMessage SEVERE: coords or merge_id == null 2006-07-11 08:58:24 org.jgroups.protocols.pbcast.CoordGmsImpl sendMergeCancelledMessage SEVERE: coords or merge_id == null ... -- 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

19 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-259) Unidentified errors with TCP/TCPPING/MERGE2 protocol stack.

by Tomasz Skutnik (JIRA)

Unidentified errors with TCP/TCPPING/MERGE2 protocol stack. ----------------------------------------------------------- Key: JGRP-259 URL: http://jira.jboss.com/jira/browse/JGRP-259 Project: JGroups Issue Type: Bug Affects Versions: 2.2.9.2 Environment: Debian GNU/Linux 2.4.27, JDK 1.5.0_05 Reporter: Tomasz Skutnik Assigned To: Bela Ban Attachments: Test1.java I've encountered connect/disconnect problems during my experiments with TCP/TCPPING/MERGE2 protocol stack. I run client program (see attachment) on 2 different hosts (witnin two VMWare virtual hosts). One of the hosts (h1) plays role of well-known host from which initial membership will be retrieved, the other plays role of plain client. I use following command lines to run client programs: - on host h1: $ java -cp \ jgroups-all-2.2.9.2.jar:concurrent.jar:commons-logging-1.1.jar:\ classes test.Test1 "h1" "h1[7800]" - on host h2 $ java -cp \ jgroups-all-2.2.9.2.jar:concurrent.jar:commons-logging-1.1.jar:\ classes test.Test1 "h2" "h1[7800]" When I run client programs in h1, h2 order everyting works fine. But if I run them in h2, h1 order, or if I kill h1 and then rerun it something weird happens: merge of two disjoint groups happens (MergeView is transmitted), but then followin exception occurs: 2006-07-10 12:01:32 org.jgroups.Message readHeader SEVERE: magic number 306192 is not available in magic map 2006-07-10 12:01:32 org.jgroups.protocols.TP handleIncomingPacket SEVERE: failed unmarshalling message java.io.IOException: failed read header: java.lang.NullPointerException at org.jgroups.Message.readHeader(Message.java:697) at org.jgroups.Message.readFrom(Message.java:614) at org.jgroups.protocols.TP.bufferToMessage(TP.java:974) at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:830) at org.jgroups.protocols.TP.receive(TP.java:781) at org.jgroups.protocols.TCP.receive(TCP.java:226) at org.jgroups.blocks.ConnectionTable.receive(ConnectionTable.java:471) at org.jgroups.blocks.ConnectionTable$Connection.run(ConnectionTable.java:813) at java.lang.Thread.run(Thread.java:595) Because there's no magic number in magic map (whatever that means) it causes NPE within org.jgroups.Message class (line 687). >From now on everything is going downhill - jgroups logs infinite stream of retransmition errors, e.g.: SEVERE: magic number 306192 is not available in magic map 2006-07-10 12:01:54 org.jgroups.protocols.pbcast.NAKACK handleXmitRsp SEVERE: message did not contain a list (LinkedList) of retransmitted messages: java.io.IOException: failed read header: java.lang.NullPointerException This flow of exceptions does not stop until all clients (h1 and h2) are killed - stopping h1 does not stop exceptions on h2 and vice versa. -- 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

19 years, 11 months

2
6
0 / 0

[JBoss JIRA] Resolved: (JGRP-243) Use ICMP ping with VERIFY_SUSPECT

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-243?page=all ] Bela Ban resolved JGRP-243. --------------------------- Resolution: Done done, new properties are use_icmp (if set, we use InetAddress.isReachable()) and bind_addr (determines which interface is used for pinging) > Use ICMP ping with VERIFY_SUSPECT > --------------------------------- > > Key: JGRP-243 > URL: http://jira.jboss.com/jira/browse/JGRP-243 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.2, 2.2.9.1, 2.2.8, 2.3, 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Priority: Minor > Fix For: 2.4 > > > Use a script or executable (like FD_PING) which can be used to verify a host is down. This could be used in addition to a heartbeat, should be configurable -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-498) StressTest.testTopicMultipleReceivers() (InVM) fails

by Ovidiu Feodorov (JIRA)

StressTest.testTopicMultipleReceivers() (InVM) fails ---------------------------------------------------- Key: JBMESSAGING-498 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-498 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Tim Fox Priority: Blocker Fix For: 1.0.1.CR4 testTopicMultipleReceivers Failure Runner 19 failed junit.framework.AssertionFailedError: Runner 19 failed at org.jboss.test.messaging.jms.stress.StressTestBase.runRunners(StressTestBase.java:146) at org.jboss.test.messaging.jms.stress.StressTest.testTopicMultipleReceivers(StressTest.java:325) -- 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

19 years, 11 months

1
3
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 August 2006