August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBMESSAGING-340) Static selector queues

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-340?page=all ] Ovidiu Feodorov updated JBMESSAGING-340: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.6) > Static selector queues > ---------------------- > > Key: JBMESSAGING-340 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-340 > Project: JBoss Messaging > Issue Type: Feature Request > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > We should consider adding functionality to allow a selector to be associated with a queue in the deployment descriptor. The queue then does not accept any messages that do not match the selector. This is in addition to the standard jms functionality of specifying selectors on message consumers. > It should give better performance in those cases where it is possible to know a selector to apply to an entire queue in advance. -- 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] Closed: (JBMESSAGING-328) Optimisation - batch messages to consumers

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-328?page=all ] Ovidiu Feodorov closed JBMESSAGING-328. --------------------------------------- Resolution: Won't Fix > Optimisation - batch messages to consumers > ------------------------------------------ > > Key: JBMESSAGING-328 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-328 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.1.CR4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Instead of sending messages to client side consumers immediately, server side consumers can batch messages up and send them periodically every x milliseconds, the same can occur in the other direction for acknowledgements. This would be likely to increase overall throughput due to reduction in lock contention on the queue due to consumers not continually asking if there are any more messages to be delivered. > The trade off here is there would be some increase in latency. -- 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] Updated: (JBMESSAGING-328) Optimisation - batch messages to consumers

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-328?page=all ] Ovidiu Feodorov updated JBMESSAGING-328: ---------------------------------------- Fix Version/s: 1.0.1.CR4 (was: 1.0.5) > Optimisation - batch messages to consumers > ------------------------------------------ > > Key: JBMESSAGING-328 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-328 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.1.CR4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Instead of sending messages to client side consumers immediately, server side consumers can batch messages up and send them periodically every x milliseconds, the same can occur in the other direction for acknowledgements. This would be likely to increase overall throughput due to reduction in lock contention on the queue due to consumers not continually asking if there are any more messages to be delivered. > The trade off here is there would be some increase in latency. -- 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] Reopened: (JBMESSAGING-328) Optimisation - batch messages to consumers

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-328?page=all ] Ovidiu Feodorov reopened JBMESSAGING-328: ----------------------------------------- > Optimisation - batch messages to consumers > ------------------------------------------ > > Key: JBMESSAGING-328 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-328 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.5 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Instead of sending messages to client side consumers immediately, server side consumers can batch messages up and send them periodically every x milliseconds, the same can occur in the other direction for acknowledgements. This would be likely to increase overall throughput due to reduction in lock contention on the queue due to consumers not continually asking if there are any more messages to be delivered. > The trade off here is there would be some increase in latency. -- 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] Updated: (JBMESSAGING-218) Persistent services are very noisy in the logs when the table(s) they are trying to create already exists

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-218?page=all ] Ovidiu Feodorov updated JBMESSAGING-218: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > Persistent services are very noisy in the logs when the table(s) they are trying to create already exists > --------------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-218 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-218 > Project: JBoss Messaging > Issue Type: Sub-task > Components: Messaging Core Persistence > Reporter: Ovidiu Feodorov > Priority: Minor > Fix For: 1.2.1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > JDBCDurableSubscriptionStore, JDBCMessageStore, JDBCTransactionLog try to create their corresponding tables during their inialization procedure and litter the logs with SQLException stack traces if the corresponding tables exist: > java.sql.SQLException: Table already exists: TRANSACTION in statement [CREATE TABLE TRANSACTION] > at org.hsqldb.jdbc.Util.sqlException(Util.java:61) > at org.hsqldb.jdbc.jdbcStatement.fetchResult(jdbcStatement.java:1580) > ..... > Use a less noisy way to insure the tables exist. Swallowing the SQLException is not a solution, since it may signal other problems with the database. -- 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] Updated: (JBMESSAGING-210) ServerPeer.createTopic(...)/createQueue(...) implementation suboptimal

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-210?page=all ] Ovidiu Feodorov updated JBMESSAGING-210: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > ServerPeer.createTopic(...)/createQueue(...) implementation suboptimal > ---------------------------------------------------------------------- > > Key: JBMESSAGING-210 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-210 > Project: JBoss Messaging > Issue Type: Task > Components: Configuration and Management > Reporter: Ovidiu Feodorov > Priority: Minor > Fix For: 1.2.1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > ServerPeer.createTopic(...)/createQueue(...) are JMX managed operations that allow to programatically create a JMS destination. The implementation is suboptimal in that it parses a literal representation of an destination MBean configuration and deploys the resulted org.w3c.dom.Element. It also accesses directly ServiceCreator and UnifiedClassLoader3 interfaces. Review the implementation. -- 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] Updated: (JBMESSAGING-353) ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-353?page=all ] Ovidiu Feodorov updated JBMESSAGING-353: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows > ----------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-353 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-353 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Facade, Tests and Performance > Affects Versions: 1.0.0, 1.0.1.CR1 > Environment: mac osx 10.4.6 > JDK 1.4.2_09 > JDK 1.5.0_04 > Reporter: Aaron Walker > Assigned To: Tim Fox > Fix For: 1.2.1 > > Attachments: messaging-tests.trace.log > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The testRedeliveryTransacted fail with the following: > 1) testRedeliveryTransacted(org.jboss.test.messaging.jms.ConnectionConsumerTest)junit.framework.AssertionFailedError: Didn't receive correct messages > at org.jboss.test.messaging.jms.ConnectionConsumerTest.testRedeliveryTransacted(ConnectionConsumerTest.java:224) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58) > The issue revolves around the sess.rollback around line 433 in that after the rollback and the 3 messages get redelivered and on the 3rd message the following if (!tm.getJMSRedelivered()) at line 481 evaluates to true in that the getJMSRedelivered() is false when it should be true. By placing a 1ms sleep just prior to the rollback you can get the test to pass. So after my initial investigation It appears that it may be some sort of threading issue that shows up on my mac. > I will attached the TRACE log for this If you look at line 765 of the log it shows that the delivery count for the message is 0 when it should be 1 -- 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] Updated: (JBMESSAGING-89) Repository reorganization

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-89?page=all ] Ovidiu Feodorov updated JBMESSAGING-89: --------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > Repository reorganization > ------------------------- > > Key: JBMESSAGING-89 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-89 > Project: JBoss Messaging > Issue Type: Task > Components: Build System > Reporter: Ovidiu Feodorov > Fix For: 1.2.1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The current JBoss Messaging CVS module (jboss-head/jms) contains unused directories and files, byproducts of alpha development and refactoring. > Clean-up the module and keep only what is necessary. > Rename the current "messaging" module "jbossmq", and change "jms" to "messaging" -- 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] Updated: (JBMESSAGING-321) Use lock free queues for JDK1.5

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-321?page=all ] Ovidiu Feodorov updated JBMESSAGING-321: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > Use lock free queues for JDK1.5 > ------------------------------- > > Key: JBMESSAGING-321 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-321 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Optional > Fix For: 1.2.1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > JDK1.5 concurrent classes utilise processor Compare and Swap (CAS) instructions to allow wait free (lock free) data struictures to be created. > We could detect whether the user is running JDK1.5 and use non blocking synchronization in our queues. Should improve concurrency. -- 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] Updated: (JBMESSAGING-254) Remove ThreadContextClassLoaderChanger

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-254?page=all ] Ovidiu Feodorov updated JBMESSAGING-254: ---------------------------------------- Fix Version/s: 1.2.1 (was: 1.0.5) > Remove ThreadContextClassLoaderChanger > -------------------------------------- > > Key: JBMESSAGING-254 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-254 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.2.1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Kabir has fixed this in AOP so this is no longer necessary. -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006