August 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBOOT-105) JMX notification not sent until after shutdown is complete

by Paul Ferraro (JIRA)

JMX notification not sent until after shutdown is complete ---------------------------------------------------------- Key: JBBOOT-105 URL: https://jira.jboss.org/jira/browse/JBBOOT-105 Project: JBoss Bootstrap Issue Type: Bug Components: impl-base Affects Versions: impl-base-2.0.0-alpha-3 Reporter: Paul Ferraro Assignee: Andrew Lee Rubinger In bootstrap 1.0.x, and in the legacy implementation, the org.jboss.system.server.stopped JMX notification was sent prior to the shutdown of the server. The AS TomcatService relies on this mechanism to stop its http/ajp connectors before stopping the service, along with any deployed web applications. In 2.0.0-alpha-3, however, this notification is not sent until after shutdown is complete. Consequently, the http/ajp connectors are not getting stopped until after all web applications are undeployed. It is now possible for a web request to reach the connectors before they are stopped, but after the requested web application was already undeployed, causing a 404 (page not found) error. -- 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

16 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1881) Service Proxy Factory not uninstalled

by Andrew Lee Rubinger (JIRA)

Service Proxy Factory not uninstalled ------------------------------------- Key: EJBTHREE-1881 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1881 Project: EJB 3.0 Issue Type: Bug Components: proxy-impl Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger When redeploying a @Service (that had previously failed during start()): Caused by: org.jboss.ejb3.common.registrar.spi.DuplicateBindException: Cannot install org.jboss.ejb3.proxy.impl.factory.session.service.ServiceRemoteProxyFactory@4cc4ee24 under name "ProxyFactory/ejbthree1738/RunAsService/RunAs/remote" as there is already an existing object there: org.jboss.ejb3.proxy.impl.factory.session.service.ServiceRemoteProxyFactory@4c6cb02a Note that an explicit jndiBinding has been provided. -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-419) Enable module unit tests for app server builds

by Paul Gier (JIRA)

Enable module unit tests for app server builds ---------------------------------------------- Key: JBBUILD-419 URL: http://jira.jboss.com/jira/browse/JBBUILD-419 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - App Server Several app server modules contain unit tests. Test scope dependencies should be added to the poms for these tests, and the tests should be enabled with the surefire plugin. -- 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

16 years, 5 months

1
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2229) Unable to remove an event listener from within the RHS of a rule

by Michael Neale (JIRA)

Unable to remove an event listener from within the RHS of a rule ---------------------------------------------------------------- Key: JBRULES-2229 URL: https://jira.jboss.org/jira/browse/JBRULES-2229 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Reporter: Michael Neale Assignee: Edson Tirelli Priority: Critical Hey Edson - was working with Solnet - they cam across this one. I have been able to reproduce it. They are asserting a listener itself as a fact, and then trying to remove this in the RHS of some rule (see attached test). interestingly, if you remove the SAME instance of the listener in regular code, it works just fine. -- 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

16 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-7162) Add mysql-xa-ds.xml to JBOSS_HOME\docs\examples\jca directory

by asookazian (JIRA)

Add mysql-xa-ds.xml to JBOSS_HOME\docs\examples\jca directory ------------------------------------------------------------- Key: JBAS-7162 URL: https://jira.jboss.org/jira/browse/JBAS-7162 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Environment: n/a Reporter: asookazian Priority: Minor JBoss 5.1.0.GA does not provide a xa-datasource example xml file for MySQL. Please add. Example (please note, this config is not fully tested!): /**********************************************************************************************************************/ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE datasources PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN" "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd"> <datasources> <xa-datasource> <jndi-name>bookingDatasource</jndi-name> <xa-datasource-property name="URL">jdbc:mysql://localhost:3306/jboss</xa-datasource-property> <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class> <user-name>jboss</user-name> <password>password</password>  <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name> <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name> <min-pool-size>1</min-pool-size> <max-pool-size>10</max-pool-size> <idle-timeout-minutes>10</idle-timeout-minutes> <metadata> <type-mapping>mySQL</type-mapping> </metadata> </xa-datasource> </datasources> -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1693) Unable to consume more than 777, 000 messages

by Bijith Kumar (JIRA)

Unable to consume more than 777,000 messages --------------------------------------------- Key: JBMESSAGING-1693 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693 Project: JBoss Messaging Issue Type: Bug Affects Versions: 2.0.0 Environment: Windows Vista, 32 bit, 2GB RAM Reporter: Bijith Kumar Assignee: Tim Fox Priority: Critical Using messaging-2.0.0.BETA3 stand alone non-clustered ------------------------------------------------------------------------------- I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages. i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue <global-page-size>10485760</global-page-size> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings) -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false Please find the attached java files. Test instructions are given below 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ". 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged). 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ" 4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing 5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount from messagedAdded. Following are the values I got for last three runs Messages Consumed = messagedAdded - MessageCount a) 800246 - 23246 = 777000 b) 799037 - 22037 = 777000 c) 799037 - 22037 = 777000 It seems the number of messages consumed (777000 in above case) is driven by message size. Because, when I tried another message, the consumption hanged after 780,000 messages. -- 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

16 years, 5 months

5
17
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1702) deadlock on application shutdown calling connection.close()

by Adrian Woodhead (JIRA)

deadlock on application shutdown calling connection.close() ----------------------------------------------------------- Key: JBMESSAGING-1702 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1702 Project: JBoss Messaging Issue Type: Bug Affects Versions: 2.0.0.beta4 Reporter: Adrian Woodhead Assignee: Tim Fox I have a client application which has a single producer and receiver. These are created as singletons by a Spring application context. I define a shutdown method in my producer which in turn calls connection.close(). This shutdown method is called by Spring when the application is shutdown. This used to work fine when my Producer used ActiveMQ, however with JBM it leads to deadlock and my application no longer shuts down cleanly. I have included the deadlock stack trace from jstack below. To me what seems to be going wrong is that while my shutdown method is calling connection.close() two other threads have called my onException handler (which calls connection.close() too). So it seems as if these 3 threads are now fighting over trying to close the connection. Am I doing something wrong here or should this work? When I do the shutdown I don't see any output from onException (the first thing I do is log a message) so is it possible that these threads are left over from some earlier onException() call? If so, then why are they blocked? I guess a simple solution could be to not call close() when my application shuts down but I'd prefer to do a clean close if possible. Deadlock stack: Found one Java-level deadlock: ============================= "Thread-8": waiting to lock monitor 0x00000000006c4370 (object 0x00007f451b6a8f30, a org.jboss.messaging.jms.client.JBossConnection), which is held by "Thread-179 (group:JBM-client-global-threads-1304545579)" "Thread-179 (group:JBM-client-global-threads-1304545579)": waiting to lock monitor 0x00000000006c4220 (object 0x00007f451b6af088, a java.lang.Object), which is held by "Thread-138 (group:JBM-client-global-threads-1304545579)" "Thread-138 (group:JBM-client-global-threads-1304545579)": waiting to lock monitor 0x00000000006c4370 (object 0x00007f451b6a8f30, a org.jboss.messaging.jms.client.JBossConnection), which is held by "Thread-179 (group:JBM-client-global-threads-1304545579)" Java stack information for the threads listed above: =================================================== "Thread-8": at org.jboss.messaging.jms.client.JBossConnection.close(JBossConnection.java:250) - waiting to lock <0x00007f451b6a8f30> (a org.jboss.messaging.jms.client.JBossConnection) at fm.last.jms.BaseJMSObject.disconnect(BaseJMSObject.java:108) at fm.last.jms.QueueingProducer.disconnect(QueueingProducer.java:86) at fm.last.jms.QueueingProducer.shutdown(QueueingProducer.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:208) at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:165) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:487) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:462) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:430) - locked <0x00007f451b55f560> (a java.util.LinkedHashMap) at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:853) at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:831) at org.springframework.context.support.AbstractApplicationContext$1.run(AbstractApplicationContext.java:764) "Thread-179 (group:JBM-client-global-threads-1304545579)": at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.removeSession(ConnectionManagerImpl.java:436) - waiting to lock <0x00007f451b6af088> (a java.lang.Object) - locked <0x00007f451b6af078> (a java.lang.Object) at org.jboss.messaging.core.client.impl.ClientSessionImpl.doCleanup(ClientSessionImpl.java:1262) at org.jboss.messaging.core.client.impl.ClientSessionImpl.close(ClientSessionImpl.java:686) at org.jboss.messaging.jms.client.JBossSession.close(JBossSession.java:278) at org.jboss.messaging.jms.client.JBossConnection.close(JBossConnection.java:259) - locked <0x00007f451b6a8f30> (a org.jboss.messaging.jms.client.JBossConnection) at fm.last.jms.BaseJMSObject.disconnect(BaseJMSObject.java:108) at fm.last.jms.QueueingProducer.disconnect(QueueingProducer.java:86) at fm.last.jms.BaseJMSObject.reconnect(BaseJMSObject.java:117) at fm.last.jms.BaseJMSObject.onException(BaseJMSObject.java:141) at org.jboss.messaging.jms.client.JBossConnection$JMSFailureListener.connectionFailed(JBossConnection.java:545) - locked <0x00007f451b6b0780> (a org.jboss.messaging.jms.client.JBossConnection$JMSFailureListener) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:402) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:244) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failoverOrReconnect(ConnectionManagerImpl.java:660) - locked <0x00007f451b6b4530> (a java.lang.Object) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.handleConnectionFailure(ConnectionManagerImpl.java:506) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.access$600(ConnectionManagerImpl.java:80) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$DelegatingFailureListener.connectionFailed(ConnectionManagerImpl.java:1194) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:402) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:244) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$FailedConnectionAction$1.run(ConnectionManagerImpl.java:1150) 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) "Thread-138 (group:JBM-client-global-threads-1304545579)": at org.jboss.messaging.jms.client.JBossConnection.close(JBossConnection.java:250) - waiting to lock <0x00007f451b6a8f30> (a org.jboss.messaging.jms.client.JBossConnection) at fm.last.jms.BaseJMSObject.disconnect(BaseJMSObject.java:108) at fm.last.jms.QueueingProducer.disconnect(QueueingProducer.java:86) at fm.last.jms.BaseJMSObject.reconnect(BaseJMSObject.java:117) at fm.last.jms.BaseJMSObject.onException(BaseJMSObject.java:141) at org.jboss.messaging.jms.client.JBossConnection$JMSFailureListener.connectionFailed(JBossConnection.java:545) - locked <0x00007f451b6a8f10> (a org.jboss.messaging.jms.client.JBossConnection$JMSFailureListener) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:402) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:244) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failoverOrReconnect(ConnectionManagerImpl.java:660) - locked <0x00007f451b6af088> (a java.lang.Object) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.handleConnectionFailure(ConnectionManagerImpl.java:506) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.access$600(ConnectionManagerImpl.java:80) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$DelegatingFailureListener.connectionFailed(ConnectionManagerImpl.java:1194) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:402) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:244) at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$FailedConnectionAction$1.run(ConnectionManagerImpl.java:1150) 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) Found 1 deadlock. -- 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

16 years, 5 months

2
12
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1703) After failure to failover or reconnect connections aren't closed

by Tim Fox (JIRA)

After failure to failover or reconnect connections aren't closed ---------------------------------------------------------------- Key: JBMESSAGING-1703 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1703 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0 If a connection fails and the connection manager does not failover or automatically reconnect, then the pingers are removed from the connections but the connections remain in the connection manager, and can be returned in subsequent calls to createSession. -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-533) Update jboss parent pom and wiki to use webdav for deploying to releases repository

by Paul Gier (JIRA)

Update jboss parent pom and wiki to use webdav for deploying to releases repository ----------------------------------------------------------------------------------- Key: JBBUILD-533 URL: https://jira.jboss.org/jira/browse/JBBUILD-533 Project: JBoss Build System Issue Type: Task Components: Maven Builds Reporter: Paul Gier Fix For: Maven Build - Maint 2009 The webdav URL (dav:https://svn.jboss.org/repos/repository.jboss.org/maven2) should be used when deploying to the jboss maven repository instead of the current method of checkout out the repository first. -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJCA-143) SJC: Support parallel deployments

by Jesper Pedersen (JIRA)

SJC: Support parallel deployments --------------------------------- Key: JBJCA-143 URL: https://jira.jboss.org/jira/browse/JBJCA-143 Project: JBoss JCA Issue Type: Task Components: Standalone Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Alpha3 Add support for parallel deployments in the SJC kernel - make it optional. This will require a dependency solution mechanism between beans. -- 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

16 years, 5 months

1
1
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 2009