July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBMESSAGING-343) Stress test with a large number of clients accessing the server in parallel

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-343?page=all ] Clebert Suconic closed JBMESSAGING-343. --------------------------------------- Resolution: Done > Stress test with a large number of clients accessing the server in parallel > --------------------------------------------------------------------------- > > Key: JBMESSAGING-343 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-343 > Project: JBoss Messaging > Issue Type: Sub-task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Clebert Suconic > Fix For: 1.4.0.CR1 > > > Push the limit of concurent clients to limit -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-343) Stress test with a large number of clients accessing the server in parallel

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-343?page=comments#action_12... ] Clebert Suconic commented on JBMESSAGING-343: --------------------------------------------- Added SeveralClientsStressTest... The test has 200 Consumers and 200 Producers... a Worker (Producer or Consumer) is closed/recreated on every minute.. The test keeps doing that for 5 minutes... This same test is also used for SoakTests > Stress test with a large number of clients accessing the server in parallel > --------------------------------------------------------------------------- > > Key: JBMESSAGING-343 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-343 > Project: JBoss Messaging > Issue Type: Sub-task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Clebert Suconic > Fix For: 1.4.0.CR1 > > > Push the limit of concurent clients to limit -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-994) set/get GlobalResolver

by Mark Proctor (JIRA)

set/get GlobalResolver ---------------------- Key: JBRULES-994 URL: http://jira.jboss.com/jira/browse/JBRULES-994 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.0.MR4 We added setGlobalResolver, getGlobalResolver is also needed. Also the working memory should no longer handle any form of chaining, should just check the provided, or default, resolver. -- 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

17 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4528) jboss-ds-1.5.dtd is not up-to-date

by Adrian Brock (JIRA)

jboss-ds-1.5.dtd is not up-to-date ---------------------------------- Key: JBAS-4528 URL: http://jira.jboss.com/jira/browse/JBAS-4528 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.2.CR1 The jboss-ds-1.5.dtd is not up-to-date, e.g. no-tx-connection-factory should support a prefill element. All the most recent features need checking to make sure they've all been updated correctly. -- 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

17 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-126) ProxyMapCreator does not handle default annotation values

by Adrian Brock (JIRA)

ProxyMapCreator does not handle default annotation values --------------------------------------------------------- Key: JBMICROCONT-126 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-126 Project: JBoss MicroContainer Issue Type: Task Components: General Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock Assigned To: Kabir Khan There is a fixme in ProxyMapCreator that says "//TODO: Need to handle default values for annotations in jdk 1.5" -- 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

17 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-124) Fixme in test org.jboss.test.classinfo.support.AnnotatedSubClass

by Adrian Brock (JIRA)

Fixme in test org.jboss.test.classinfo.support.AnnotatedSubClass ---------------------------------------------------------------- Key: JBMICROCONT-124 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-124 Project: JBoss MicroContainer Issue Type: Task Components: General Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock Assigned To: Kabir Khan Priority: Minor There is a FIXME in the above class. Kabir can you update this task to describe the problem. -- 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

17 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-920) Rules - in ESB Content Based Router - reports error reading rules file with CR/NL line endings

by Len DiMaggio (JIRA)

Rules - in ESB Content Based Router - reports error reading rules file with CR/NL line endings ---------------------------------------------------------------------------------------------- Key: JBRULES-920 URL: http://jira.jboss.com/jira/browse/JBRULES-920 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR2 Environment: JBoss ESB - from svn 20070612 drools-compiler-4.0.0.11754MR2.jar drools-core-4.0.0.11754MR2.jar drools-decisiontables-4.0.0.11754MR2.jar drools-jsr94-4.0.0.11754MR2.jar Reporter: Len DiMaggio Assigned To: Mark Proctor Priority: Minor Attachments: MyESBRules-XPath.drl.CRNL It's a non-fatal error: ERROR [STDERR] line 7:0 no viable alternative at character '\r' The problem was first reported here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110672 -- 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

17 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-553) Deadlock in FD protocol

by Bela Ban (JIRA)

Deadlock in FD protocol ----------------------- Key: JGRP-553 URL: http://jira.jboss.com/jira/browse/JGRP-553 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 SP4, 2.5 [submitted by Oleg Afanasiev (xbalanque at mail.ru)] I found the following deadlock in protocol FD: Found one Java-level deadlock: ============================= "IncomingPacketHandler (channel=+slee_5servers)": waiting to lock monitor 0x0000002b80fcd488 (object 0x0000002aa7788330, a java.lang.Object), which is held by "Timer-4" "Timer-4": waiting to lock monitor 0x0000002b80fcd848 (object 0x0000002aa778adc8, a java.util.Vector), which is held by "IncomingPacketHandler (channel=+slee_5servers)" Java stack information for the threads listed above: =================================================== "IncomingPacketHandler (channel=+slee_5servers)": at org.jgroups.protocols.FD$Broadcaster.stopBroadcastTask (FD.java:602) - waiting to lock <0x0000002aa7788330> (a java.lang.Object) at org.jgroups.protocols.FD$Broadcaster.adjustSuspectedMembers (FD.java:649) - locked <0x0000002aa778adc8> (a java.util.Vector) at org.jgroups.protocols.FD.down(FD.java:318) - locked <0x0000002aa7083c08> (a org.jgroups.protocols.FD) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.stack.Protocol.down(Protocol.java:559) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:480) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.protocols.UNICAST.down(UNICAST.java:391) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:287) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:166) at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java: 499) at org.jgroups.stack.Protocol.passDown(Protocol.java:533) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:509) - locked <0x0000002aa76ee7e0> (a org.jgroups.Membership) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange (CoordGmsImpl.java:568) ... "Timer-4": at java.util.Vector.clone(Vector.java:638) - waiting to lock <0x0000002aa778adc8> (a java.util.Vector) at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask (FD.java:587) - locked <0x0000002aa7788330> (a java.lang.Object) at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember (FD.java:621) at org.jgroups.protocols.FD$Monitor.run(FD.java:541) at org.jgroups.util.TimeScheduler$TaskWrapper.run (TimeScheduler.java:204) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) The source of deadlock is the following piece of code: If addSuspectedMember from own timer task and adjustSuspectedMembers from GMS arrive simultaneously, we've got a deadlock on method clone(). protected final class Broadcaster { final Vector suspected_mbrs=new Vector(7); BroadcastTask task=null; private final Object bcast_mutex=new Object(); Vector getSuspectedMembers() { return suspected_mbrs; } /** * Starts a new task, or - if already running - adds the argument to the running task. * @param suspect */ private void startBroadcastTask(Address suspect) { synchronized(bcast_mutex) { if(task == null || task.cancelled()) { task=new BroadcastTask((Vector) suspected_mbrs.clone()); /// this clone method is synchronized and causes a deadlock task.addSuspectedMember(suspect); task.run(); // run immediately the first time timer.add(task); // then every timeout milliseconds, until cancelled if(log.isTraceEnabled()) log.trace("BroadcastTask started"); } else { task.addSuspectedMember(suspect); } } } private void stopBroadcastTask() { synchronized(bcast_mutex) { if(task != null) { task.stop(); task=null; } } } /** Adds a suspected member. Starts the task if not yet running */ protected void addSuspectedMember(Address mbr) { if(mbr == null) return; if(!members.contains(mbr)) return; boolean added=false; synchronized(suspected_mbrs) { if(!suspected_mbrs.contains(mbr)) { suspected_mbrs.addElement(mbr); added=true; } } if(added) startBroadcastTask(mbr); } void removeSuspectedMember(Address suspected_mbr) { if(suspected_mbr == null) return; if(log.isDebugEnabled()) log.debug("member is " + suspected_mbr); synchronized(suspected_mbrs) { suspected_mbrs.removeElement(suspected_mbr); if(suspected_mbrs.isEmpty()) stopBroadcastTask(); } } void removeAll() { synchronized(suspected_mbrs) { suspected_mbrs.removeAllElements(); stopBroadcastTask(); } } /** Removes all elements from suspected_mbrs that are <em>not</em> in the new membership */ void adjustSuspectedMembers(List new_mbrship) { if(new_mbrship == null || new_mbrship.isEmpty()) return; StringBuffer sb=new StringBuffer(); synchronized(suspected_mbrs) { sb.append("suspected_mbrs: ").append(suspected_mbrs); suspected_mbrs.retainAll(new_mbrship); if(suspected_mbrs.isEmpty()) stopBroadcastTask(); sb.append(", after adjustment: ").append (suspected_mbrs); log.debug(sb.toString()); } } } The proposed solution is to move startBroadcastTask() back inside synchronized(suspected_mbrs) block in the addSuspectedMember method. So it'll look like: /** Adds a suspected member. Starts the task if not yet running */ protected void addSuspectedMember(Address mbr) { if(mbr == null) return; if(!members.contains(mbr)) return; boolean added=false; synchronized(suspected_mbrs) { if(!suspected_mbrs.contains(mbr)) { suspected_mbrs.addElement(mbr); startBroadcastTask(mbr); } } } Or we may use a separate monitor for operations that use suspected_mbrs to synchronize. -- 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

17 years, 3 months

1
3
0 / 0

[JBoss JIRA] Resolved: (JBMICROCONT-93) Add JBossRetro builds for Microcontainer projects

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=all ] Paul Gier resolved JBMICROCONT-93. ---------------------------------- Resolution: Done I'm going to close this issue for now, and when the maven issues are resolved, I will add the retro tests. > Add JBossRetro builds for Microcontainer projects > ------------------------------------------------- > > Key: JBMICROCONT-93 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Paul Gier > Fix For: JBossMC_2_0_0_CR1 > > > Make JBossRetro builds for the microcontainer projects > such that they can use JDK5 features. -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMICROCONT-93) Add JBossRetro builds for Microcontainer projects

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-93?page=comments#action_123... ] Paul Gier commented on JBMICROCONT-93: -------------------------------------- The retro jars are being created during builds, but I haven't set up the retroed unit tests yet. There is an issue with the maven surefire plugin that makes it difficult to run the retroed unit tests. I submitted a patch for the surefire plugin issue, but it hasn't been released yet. Once that gets released, then I can set up the retro tests. > Add JBossRetro builds for Microcontainer projects > ------------------------------------------------- > > Key: JBMICROCONT-93 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-93 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Paul Gier > Fix For: JBossMC_2_0_0_CR1 > > > Make JBossRetro builds for the microcontainer projects > such that they can use JDK5 features. -- 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

17 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007