September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAS-1333) connectionFailure

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1333?page=all ] Adrian Brock closed JBAS-1333. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > connectionFailure > ----------------- > > Key: JBAS-1333 > URL: http://jira.jboss.com/jira/browse/JBAS-1333 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final > Reporter: Adrian Brock > > The connectionFailure invocation from the IL layer needs to pass through the interceptor > rather than just invoking on the destination manager. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1585) Enhance Queue throughput

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1585?page=all ] Adrian Brock closed JBAS-1585. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Enhance Queue throughput > ------------------------ > > Key: JBAS-1585 > URL: http://jira.jboss.com/jira/browse/JBAS-1585 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Reporter: Ivelin Ivanov > > > -----Original Message----- > > From: Adrian Brock > > Sent: Monday, March 14, 2005 2:35 PM > > To: Ivelin Ivanov > > Cc: Stan Silvert; Neal Byrd; The Core; Rebecca Goldstein > > Subject: RE: JMS Reference > > > ... > > I know you can get about x8 improvement in JBossMQ just by adding > > some simple flow control. > > > > Instead of doing the "one in, one out" policy on the message cache > > when memory is tight (i.e. move some old messages to disk to make > > room for the new messages) > > I did a simple test instead with > > Thread.sleep(1000); > > to slow down the senders and let the receivers clear some memory. > > > > The message throughput went from 1 million messages/hour to 8 million. > > I did this test around JBoss-3.0.7 time when the performance was > > very poor. > > > > I discarded the idea as too simplistic since the mechanism > > requires blocking server threads. But it does show JBossMQ > > could easily be improved if we had the motivation/resources > > to work on the performance without degrading its reliability. > > -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2444) Keeping Ordering after message NACK

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2444?page=all ] Adrian Brock closed JBAS-2444. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Keeping Ordering after message NACK > ----------------------------------- > > Key: JBAS-2444 > URL: http://jira.jboss.com/jira/browse/JBAS-2444 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > > There is a common FAQ about how to keep message ordering in the event of failure (i.e. a NACK or transaction rollback). > JMS gives no such guarantees. > However, we could give that guarantee at the expense of throughput. > Basically what we need to do is not allow anybody to receive() a message until the single message (or group of messages > in the same transaction) that has already been received is either nacked or acked. > Once the nack (rollback) comes from the client that has the "checked out" message it will be reinserted back into the Queue > at the top of the list and then we allow the next receive() to run. > Meaning it always the nacked message and can't get any other message until the top message is acked. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2492) Add an removeReceiver() to the receive(long timeout) processing

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2492?page=all ] Adrian Brock closed JBAS-2492. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Add an removeReceiver() to the receive(long timeout) processing > --------------------------------------------------------------- > > Key: JBAS-2492 > URL: http://jira.jboss.com/jira/browse/JBAS-2492 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > > Currently if the receive(long) times out, the receiver is left as waiting for a message on the server. > This doesn't cause any semantic problems, but it can lead to an unnecessary > deliver/nack lifecyle if there is no subsequent receive() request and the receiver is not closed. > It would be better to have the option for receive(long) to issue an removeReceiver > when it stops waiting. > However, this requires an incompatible change to the IL - there is currently no such method in the interface. > It would also need to be implementated carefully to avoid a race condition with > connection.start/stop(). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1337) Thread Pool improvements on the server

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1337?page=all ] Adrian Brock closed JBAS-1337. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Thread Pool improvements on the server > -------------------------------------- > > Key: JBAS-1337 > URL: http://jira.jboss.com/jira/browse/JBAS-1337 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Original Estimate: 6 weeks > Remaining Estimate: 6 weeks > > There are a number of different components on the server that use thread pools. > 1) Invocation Layers > 2) Client Consumer for delivering messages > 3) Scheduled delivery/message expiration > These need to be combined to share threads and minimize context switching where possible. > The thread pool should be based on the BasicThreadPool from jboss-common -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1343) ReadAhead and DUPS_OK message acknowledgement

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1343?page=all ] Adrian Brock closed JBAS-1343. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > ReadAhead and DUPS_OK message acknowledgement > --------------------------------------------- > > Key: JBAS-1343 > URL: http://jira.jboss.com/jira/browse/JBAS-1343 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > > Performance can be improved by sending mulitple messages in one request to the client > when they are using a MessageListener. > Similary, there is no implementation of DUPS_OK message acknowledgement, which would > reduce the number of network requests required to acknowledge receipt of messages. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1340) Lazily Loading Queues

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1340?page=all ] Adrian Brock closed JBAS-1340. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Lazily Loading Queues > --------------------- > > Key: JBAS-1340 > URL: http://jira.jboss.com/jira/browse/JBAS-1340 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > > This is a major change that is the last obstacle to JBossMQ scalability. > The idea is that messages will only be loaded into the server when the destination is activated > and then only part of the messages are loaded (enough to deal with the current throughput). > An attempt was made to do this and committed on Branch JBoss_3_2_5_JBossMQ_Lazy but the > work was abandoned. It does not deal with the more difficult problems. > In any case, the BasicQueues should be talking directly with the PersistenceManager. > In fact, I would favour that the BasicQueue implementation is actually pluggable and > determined by the PM to allow better optimization between these two important layers. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1338) Thread Pool improvements on the client

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1338?page=all ] Adrian Brock closed JBAS-1338. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Thread Pool improvements on the client > -------------------------------------- > > Key: JBAS-1338 > URL: http://jira.jboss.com/jira/browse/JBAS-1338 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > > The thread usage on the client needs to be improved. > The users of threads are: > 1) The invocation layers for message delivery > 2) The message listeners to wait for messages > These should be combinded to use a single thread pool. > There is no need for a message listener to hold a thread while it is waiting for a message. > It can add itself to a registry which is then used by delivery to invoke the correct listener > when a message arrives. > In fact, by spec the listeners should register themselves with the session and the session > deliver the messages (single threadedly - is that a word? :-). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1339) Persistence Manager Improvements

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1339?page=all ] Adrian Brock closed JBAS-1339. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Persistence Manager Improvements > -------------------------------- > > Key: JBAS-1339 > URL: http://jira.jboss.com/jira/browse/JBAS-1339 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > > There are a number of improvements that can be made to the persistence manager. > This should really be done by writing a new version that can then be optionally used while > it is experimental. > 1) Make use of the datasource mappings - similar what has been done for the EJB timer > 2) The use of the JTA transaction is unnecessary since we are the only one in the transaction branch. The tranaction still needs suspending so we are isolated from any wrapping transacton. > 3) Make use of build writes to the database > This can be used for transactional sessions where multiple messages are processed > But it could also be used where people want to relax the absolute requirement that > messages are persisted in return for some performance improvement. > 4) A general review/rewrite of where the persistence manager is invoked from the > server with an aim to improve performance. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-315) Create check list of manual tests

by Bela Ban (JIRA)

Create check list of manual tests --------------------------------- Key: JGRP-315 URL: http://jira.jboss.com/jira/browse/JGRP-315 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g. - JGroups/doc/tests/GmsTests.txt - Pull-the-plug scenario with UDP, TCP, TCP_NIO -- 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, 10 months

1
3
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 September 2006