February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-776) Specify one way thread pool on the server side too

by Tim Fox (JIRA)

Specify one way thread pool on the server side too -------------------------------------------------- Key: JBMESSAGING-776 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-776 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Fix For: 1.2.0.Beta2 We are currently not specifying metadata.put(ServerInvoker.ONEWAY_THREAD_POOL_CLASS_KEY, "org.jboss.jms.server.remoting.DirectThreadPool"); On the server side, only on the client side. Need to do this on the server side too, otherwise any one way invocations (e.g. changeRate) will unnecessarily be invoked via a thread pool. -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-740) Make sure wireformat is just right

by Tim Fox (JIRA)

Make sure wireformat is just right ---------------------------------- Key: JBMESSAGING-740 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-740 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1 We need to get the wireformat exactly right before the 1.2 release since changing it aftwerwards is going to give compatibility issues. We should analyse it and make sure it is exactly correct. Suggestion would be to provide a custom wire format for all invocations, not just the few we currently have so we don't rely on java/jboss serialization. Also wireformat for ping -- 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, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-721) Message redelivery doesn't work

by Amit Bhayani (JIRA)

Message redelivery doesn't work -------------------------------- Key: JBMESSAGING-721 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-721 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.0.1.SP2 Reporter: Amit Bhayani Assigned To: Ovidiu Feodorov Priority: Critical Fix For: 1.0.2.CR1 Attachments: mdb.zip Message redelivery in CMT MDB is not working. I set the transaction to setRollbackOnly on MessageDrivenContext within onMessage of MDB and ideally the message should get redelivered. I can see that Message reamins in the queue for long time. No error message is shown in server.log file. I have created a simple testcase (attached here). Sender.java send's 6 messages. Messages 1,2,3,4 and 5 are consumed however for message 6 MDBExample.java sets the setRollbackOnly after this there is no activity and message 6 remains in the queue. This testcase is from jboss-messaging-1.0.1.SP2-src\docs\examples\mdb. Just replace the files to test. -- 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, 11 months

4
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-638) Potential memory leak when using 2pc via JCA adapter.

by Tim Fox (JIRA)

Potential memory leak when using 2pc via JCA adapter. ----------------------------------------------------- Key: JBMESSAGING-638 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-638 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.GA Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.0.2.CR1 Martin Welss has reported a potential memory leak when using 2pc via the JCA adaptor. It seems that client side TxState instances remain in the resource manager. Need to investigate further. -- 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, 11 months

2
11
0 / 0

[JBoss JIRA] Assigned: (JBAS-1437) RAR MetaData Repository

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1437?page=all ] Weston Price reassigned JBAS-1437: ---------------------------------- Assignee: Weston Price > RAR MetaData Repository > ----------------------- > > Key: JBAS-1437 > URL: http://jira.jboss.com/jira/browse/JBAS-1437 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Weston Price > Priority: Minor > > Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48681 > Implement a RAR MetaData repository. > There are two use cases of this object: > * A tool wants to retrieve information about how to configure a RAR deployment > either inbound/outbound or admin object > * Avoiding the need to specify the rar-name in jboss.xml, -ds.xml or admin object deployments when > only one rar implements the connection definition or message listener. > Design: > 1) When a RAR is deployed/undeployed update the repository with information about the RAR including > cross references by > * ConnectionDefinition > * MessageListener > * AdminObject > 2) When an MDB is deployed without identifying the rar, use the repository to try to guess the RAR > 3) When a ConnectionFactory is deployed without identifying the rar, use the repository to try to guess the RAR > 4) When an AdminObject is deployed without identifying the rar, use the repository to try to guess the RAR > The algorithm to guess the RAR is > a) Is there only one RAR implementing the object > b) If there is more than one RAR, is there a specific RAR in the same top level deployment (EAR) > as the referencing deployment -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-963) Eviction thread timer is not a daemon

by Brian Stansberry (JIRA)

Eviction thread timer is not a daemon ------------------------------------- Key: JBCACHE-963 URL: http://jira.jboss.com/jira/browse/JBCACHE-963 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2, 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA, 1.3.0.SP4, 1.3.0.GA, 1.2.4SP2, 1.2.4, 1.4.1.SP1 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 The Timer used for the eviction thread needs to have true passed to it's constructor, otherwise it prevents shutdown of the application if stopService() is not invoked. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-773) isLocalInterceptor will invoke local bean when the proxy is remote

by William DeCoste (JIRA)

isLocalInterceptor will invoke local bean when the proxy is remote ------------------------------------------------------------------ Key: EJBTHREE-773 URL: http://jira.jboss.com/jira/browse/EJBTHREE-773 Project: EJB 3.0 Issue Type: Bug Reporter: William DeCoste Assigned To: William DeCoste IsLocalInterceptor checks to see if the container is local based on the OID (e.g. jboss.j2ee:jar=stateless-test.jar,name=CheckedStatelessBean,service=EJB3) via Ejb3Registry.getContainer(oid.toString()). If the bean is deployed identically to the local and remote server and the proxy is remote, the call will still be handled locally. Checking the Ejb3Registry doesn't work in this case. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-965) Inadvertent dependency on JGroups 2.2.9

by Manik Surtani (JIRA)

Inadvertent dependency on JGroups 2.2.9 --------------------------------------- Key: JBCACHE-965 URL: http://jira.jboss.com/jira/browse/JBCACHE-965 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.GA Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 1.4.1.SP1 A lousy log statement was using JBCMethodCall.getId() which introduced a dep on JG 2.2.9. -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-270) JMSQueueListener doesn't manage Thread creation for the ActionProcessingPipeline i.e. can be flooded with messages

by Tom Fennelly (JIRA)

JMSQueueListener doesn't manage Thread creation for the ActionProcessingPipeline i.e. can be flooded with messages ------------------------------------------------------------------------------------------------------------------ Key: JBESB-270 URL: http://jira.jboss.com/jira/browse/JBESB-270 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 RC1 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 5.0 This listener receives messages from a JMS queue and spawns a new thread for the ActionProcessingPipeline instance that is created to process the message. If you hammer this listener with messages (e.g 20 concurrent threads continually pumping messages into the in queue), you'll kill the process through running out of threads to process the messages. The listener should manage the Threads. Use of a Threadpool would probably take care of this for you i.e. can probably get the pool to block while waiting for a free thread to be returned to the pool. -- 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, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-401) During Trailblazer DEMO, JMS doesn't reconnect after a restart of the App Server [JMS Provider]

by Bruno Georges (JIRA)

During Trailblazer DEMO, JMS doesn't reconnect after a restart of the App Server [JMS Provider] ----------------------------------------------------------------------------------------------- Key: JBESB-401 URL: http://jira.jboss.com/jira/browse/JBESB-401 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.0 Environment: JBoss ESB 4.0 GA + JBoss AS 4.0.5GA - Win 2000 - Fedora Core 6 Reporter: Bruno Georges Assigned To: Mark Little Fix For: 4.0 Maintenance Pack 1 During Trailblazer DEMO, JMS doesn't reconnect when App Server restart: ERROR [JmsCourier] JMS error. Attempting JMS reconnect. ant runJMSBank [java] 10:00:01,759 WARN [Connection] Connection failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more ant runESB [java] 09:58:52,056 ERROR [JmsCourier] JMS error. Attempting JMS reconnect. [java] javax.jms.IllegalStateException: The consumer is closed [java] at org.jboss.mq.SpyMessageConsumer.checkClosed(SpyMessageConsumer.java:963) [java] at org.jboss.mq.SpyMessageConsumer.receive(SpyMessageConsumer.java:360) [java] at org.jboss.internal.soa.esb.couriers.JmsCourier.pickup(JmsCourier.java:349) [java] at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:184) [java] at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:166) [java] at org.jboss.soa.esb.listeners.message.MessageAwareListener.waitForEventAndProcess(MessageAwareListener.java:246) [java] at org.jboss.soa.esb.listeners.message.MessageAwareListener.doRun(MessageAwareListener.java:228) [java] at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.run(AbstractThreadedManagedLifecycle.java:114) [java] at java.lang.Thread.run(Thread.java:595) [java] 09:59:51,775 WARN [Connection] Connection failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 09:59:52,056 ERROR [JmsCourier] JMS error. Attempting JMS reconnect. -- 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, 11 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007