August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAS-3332) org.jboss.test.jbossmq.test.UnackedUnitTestCase - testUnackedQueue occasionally fails

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3332?page=all ] Adrian Brock closed JBAS-3332. ------------------------------ Resolution: Duplicate Issue JBAS-3221 > org.jboss.test.jbossmq.test.UnackedUnitTestCase - testUnackedQueue occasionally fails > ------------------------------------------------------------------------------------- > > Key: JBAS-3332 > URL: http://jira.jboss.com/jira/browse/JBAS-3332 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Dimitris Andreadis > Fix For: JBossAS-3.2.8.SP2 > > > testUnackedQueue Failure Queue should be full > junit.framework.AssertionFailedError: Queue should be full > at org.jboss.test.jbossmq.test.UnackedUnitTestCase.runUnackedQueue(UnackedUnitTestCase.java:123) > at org.jboss.test.jbossmq.test.UnackedUnitTestCase.testUnackedQueue(UnackedUnitTestCase.java:422) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > -- 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: (JBAS-3568) UnackedUnitTestCase test failure when using the IBM JVM

by Matt Wringe (JIRA)

UnackedUnitTestCase test failure when using the IBM JVM ------------------------------------------------------- Key: JBAS-3568 URL: http://jira.jboss.com/jira/browse/JBAS-3568 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Environment: IBM 1.4.2 JDK Linux Kernel 2.6.9 Reporter: Matt Wringe The org.jboss.test.jbossmq.test.UnackedUnitTestCase testUnackedDurableTopic test fails when the IBM JDK is used. Error from the test report: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null] javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null] at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92) at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142) at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541) at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:311) at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157) at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:779) at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java(Inlined Compiled Code)) at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java(Compiled Code)) at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java(Compiled Code)) at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java(Compiled Code)) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java(Compiled Code)) at java.lang.Thread.run(Thread.java(Compiled Code)) -- 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] Updated: (JBAS-3221) Need to rewrite JBossMQ tests to be more robust

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3221?page=all ] Adrian Brock updated JBAS-3221: ------------------------------- Summary: Need to rewrite JBossMQ tests to be more robust (was: JMSContainerInvokerQueueMessageDrivenUnitTestCase failures) > Need to rewrite JBossMQ tests to be more robust > ----------------------------------------------- > > Key: JBAS-3221 > URL: http://jira.jboss.com/jira/browse/JBAS-3221 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service, Test Suite > Affects Versions: JBossAS-4.0.4.GA > Reporter: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure: > <testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891"> > <error message="Wrong number of messages, expected=2 > got=1" type="java.lang.Exception">java.lang.Exception: Wrong > number of messages, expected=2 got=1 > at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46) > at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112) > at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67) > From Adrian: > The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail. > The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy. > The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits. > In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state. > e.g. The jms queue is empty or a thread pool has no scheduled work, etc. -- 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: (JBMICROCONT-35) Allow retrieval of the collection instance from the bean

by Rashid Kamran (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-35?page=comments#action_123... ] Rashid Kamran commented on JBMICROCONT-35: ------------------------------------------ Whatever you are saying is correct but conventionally a <property> tag is supposed to call a setXXX method and setter methods are supposed to overwrite the properties completely. Because the way its now a constructor could add three elements as default and one can add two more from the configuration file and this is inconsistency because as a programmer my intention would be to give defaults in the code and overwrite defaults using properties. while you are merging both.. It's not conventional > Allow retrieval of the collection instance from the bean > -------------------------------------------------------- > > Key: JBMICROCONT-35 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-35 > Project: JBoss MicroContainer > Issue Type: Task > Components: MetaData > Reporter: Adrian Brock > Assigned To: Ales Justin > Fix For: JBossMC_2_0_0M1 > > > See org.jboss.test.kernel.config.test.CollectionTestCase#TODOtestCustomCollectionPreInstantiated > Same issues apply to Lists, Sets, Maps, Arrays, etc. > i.e. If the bean already has a collection value for the property that can be > retrieved using the getter, we should be able to use that collection instance. > Need to think about the configuration options and rules. > Current rules are: > 1) Use class specified in metadata > 2) Use class specified on setter (if not an interface) > 3) Use ArrayList -- 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: (JBAS-3575) Standalone server configuration for of HA-JMS

by Luc Texier (JIRA)

Standalone server configuration for of HA-JMS --------------------------------------------- Key: JBAS-3575 URL: http://jira.jboss.com/jira/browse/JBAS-3575 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.4.GA Reporter: Luc Texier Assigned To: Luc Texier Priority: Minor Fix For: JBossAS-4.0.5.CR1 Today, as explained in this wiki, one may create a standalone version of JBossMQ http://wiki.jboss.org/wiki/Wiki.jsp?page=IsThereAStandaloneDistributionOf... users have requested the same for HA-JMS a.k.a JBossMQ clustered -- 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
2
0 / 0

[JBoss JIRA] Created: (JBRULES-398) functions have their own area, like rules, packages also reference these

by Michael Neale (JIRA)

functions have their own area, like rules, packages also reference these ------------------------------------------------------------------------ Key: JBRULES-398 URL: http://jira.jboss.com/jira/browse/JBRULES-398 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale For ben -- 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
1
0 / 0

[JBoss JIRA] Resolved: (JBMICROCONT-35) Allow retrieval of the collection instance from the bean

by Ales Justin (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-35?page=all ] Ales Justin resolved JBMICROCONT-35. ------------------------------------ Fix Version/s: JBossMC_2_0_0M1 (was: JBossMC_2_0_0 final) Resolution: Done Added preinstantiated lookup into AbstractTypeMetaData. > Allow retrieval of the collection instance from the bean > -------------------------------------------------------- > > Key: JBMICROCONT-35 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-35 > Project: JBoss MicroContainer > Issue Type: Task > Components: MetaData > Reporter: Adrian Brock > Assigned To: Ales Justin > Fix For: JBossMC_2_0_0M1 > > > See org.jboss.test.kernel.config.test.CollectionTestCase#TODOtestCustomCollectionPreInstantiated > Same issues apply to Lists, Sets, Maps, Arrays, etc. > i.e. If the bean already has a collection value for the property that can be > retrieved using the getter, we should be able to use that collection instance. > Need to think about the configuration options and rules. > Current rules are: > 1) Use class specified in metadata > 2) Use class specified on setter (if not an interface) > 3) Use ArrayList -- 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: (JBAS-3272) update JBossRemoting to version 2.0.0

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3272?page=all ] Dimitris Andreadis updated JBAS-3272: ------------------------------------- Fix Version/s: JBossAS-4.0.5.GA (was: JBossAS-4.0.5.CR1) JBoss 4.0.5.CR1 will ship with remoting v1.4.3.GA & jbossws 1.0.3.GA > update JBossRemoting to version 2.0.0 > ------------------------------------- > > Key: JBAS-3272 > URL: http://jira.jboss.com/jira/browse/JBAS-3272 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remoting > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: JBossAS-4.0.5.GA > > > Need to update JBossAS to include jboss-remoting.jar for version 2.0.0.GA of JBossRemoting. -- 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: (JBAS-3458) Out of synch run.bat/run.sh, hotspot -server usage

by Scott M Stark (JIRA)

Out of synch run.bat/run.sh, hotspot -server usage -------------------------------------------------- Key: JBAS-3458 URL: http://jira.jboss.com/jira/browse/JBAS-3458 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Reporter: Scott M Stark Fix For: JBossAS-4.0.5.CR1 The run.bat/run.sh are out of synch with respect to settings such as hotspot -server flag, and run.conf is unconditionally adding -server when this is set contitionally in run.sh. We need to clean this up. -- 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

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-280) Problem with Multiplexer and state transfer

by Bela Ban (JIRA)

Problem with Multiplexer and state transfer ------------------------------------------- Key: JGRP-280 URL: http://jira.jboss.com/jira/browse/JGRP-280 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1, 2.3 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Was looking at server logs from a testsuite run when I noticed something odd. We've got a 2 node cluster, node0 and node1, running the "all" config. Sequence of events: 1) node0 starts; as part of normal start of an "all" config 5 different services deploy sharing a channel (4 JBC instances + ClusterPartition) 2) Then node1 starts, and deploys the same 5 services. All is fine, incl state transfers from node0. 3) Test driver copies to node0/deploy a sar with 3 more services that use the same channel as the previous 5. This goes fine on node0, but on node1 I find a bunch of ERROR and WARN messages in the log (see below). 4) Test driver copies sar to node1/deploy. The 3 services deploy on node1 without problem; no further error messages. 5) The test itself passes fine; I just happened to see the following in the logs. Following are the messages. Looks like 1) node1 gets a state transfer request for the BadPartition-TreeCache service, which AFAICT it shouldn't. 2) The Multiplexer throws an exception on the request instead of logging a WARN, and 3) when the Multiplexer gets a view for a service it doesn't have, it logs a WARN, which should probably be an INFO, as its not a sign of something wrong in this case. 2006-08-20 19:55:00,593 ERROR [STDERR] java.lang.IllegalArgumentException: didn't find service with ID=BadPartition-TreeCache to fetch state from 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.mux.Multiplexer.handleStateRequest(Multiplexer.java:490) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.mux.Multiplexer.up(Multiplexer.java:260) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.JChannel.up(JChannel.java:1082) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.pbcast.STATE_TRANSFER.requestApplicationStates(STA TE_TRANSFER.java:308) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:137) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.FRAG2.up(FRAG2.java:197) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.FC.up(FC.java:344) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:753) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:773) 2006-08-20 19:55:00,593 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:154) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.protocols.UNICAST.up(UNICAST.java:224) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.passUp(Protocol.java:538) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:428) 2006-08-20 19:55:00,609 ERROR [STDERR] at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517) -- 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
2
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