June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-877) Optimise browsing

by Tim Fox (JIRA)

Optimise browsing ----------------- Key: JBMESSAGING-877 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-877 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Currently browsing is inefficient and copies the entire set of message references. Instead we should use the deque iterator + the deliveries iterator. We should also investigate activating the browsing interceptor to batch 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

16 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-871) Optimisations

by Tim Fox (JIRA)

Optimisations ------------- Key: JBMESSAGING-871 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-871 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Super task for various performance related optimisations -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-878) Consider using multicast or reliable multicast for message delivery

by Tim Fox (JIRA)

Consider using multicast or reliable multicast for message delivery ------------------------------------------------------------------- Key: JBMESSAGING-878 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-878 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 We could use multicast or jgroups reliable multicast for delivery of messages from server to client when there are many subscribers - currently this is point to point. -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-874) INVM persistent message optimisation

by Tim Fox (JIRA)

INVM persistent message optimisation ------------------------------------ Key: JBMESSAGING-874 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-874 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 For persistent messages sent in vm, the message gets converted to a byte[] before db storage, it then gets converted back to a payload on recepipt - this is unnecessary - for the invm case. We should deal with it optimally. -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-998) Impelment security for temporary destinations

by Sergey Koshcheyev (JIRA)

Impelment security for temporary destinations --------------------------------------------- Key: JBMESSAGING-998 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-998 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Security Reporter: Sergey Koshcheyev Assigned To: Tim Fox There should probably be some attribute on the ConnectionFactory to set permissions required to use temporary destinations. See the forum thread for discussion. -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-784) Add Active/Passive deployment feature for JBoss Messaging in 2 node cluster (Need HA part and not Clustering part)

by Rohit Chowdhary (JIRA)

Add Active/Passive deployment feature for JBoss Messaging in 2 node cluster (Need HA part and not Clustering part) ------------------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-784 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-784 Project: JBoss Messaging Issue Type: Task Components: JMS Clustering Affects Versions: 1.2.1 Reporter: Rohit Chowdhary Assigned To: Ovidiu Feodorov Need to be able to deploy JBoss Messaging nodes in a HA configuration, but not load-balanced. Such that only one node is actively serving all the requests, if the current active node goes down, then the passive node picks up the load. Reason would be: To use the available h/w resources at best. We have one dedicated physical server for running JBoss msg. Another physical server that hosts existing JBoss instance running some application. We want to use this second server running a passive JBossMsg instance. So in case when the dedicated JBossMsg goes down, then the second shared server can take the load temporarily automatically, till we bring back the dedicated up again. Other reason would be that we bring down the dedicated JBossMsg server for OS level patching, essentially minimizing the app downtime and increase availablity. -- 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, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-838) Test scenario where no failover has occurred on server side...

by Tim Fox (JIRA)

Test scenario where no failover has occurred on server side... -------------------------------------------------------------- Key: JBMESSAGING-838 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-838 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta2 Reporter: Tim Fox Fix For: 1.2.0.GA When a client thinks the server has failed e.g. the netwrk between client--server temporarily fails but the network between server--server is ok, the server will return -1 to say no failover is occurring or times out then the client will retry the orginal node after a pause. The pause needs to be made configurable and a test devised to test this situation -- 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, 3 months

3
11
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-963) Find a better place to put config files

by Tim Fox (JIRA)

Find a better place to put config files --------------------------------------- Key: JBMESSAGING-963 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-963 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.0.SP2 Currently config files in the source tree are store in source/etc/server/default/deploy/... This seems unintuitive and somewhat clunky. Find a better more intuitive place to put them and update scripts accordingly. -- 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, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-958) Ability to replay queues

by Tim Fox (JIRA)

Ability to replay queues ------------------------ Key: JBMESSAGING-958 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-958 Project: JBoss Messaging Issue Type: Feature Request Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 It would be good to have an ability to "replay" queues. I.e. when messages are acked, they don't necessarily get removed from the queue, instead a pointer on the queue just moves to the next element. This would allow recovery scenarios where the queue can be replayed, by resetting the pointer and redelivering 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

16 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-742) Message.getJMSDestination could be null on redeployment of a queue

by Clebert Suconic (JIRA)

Message.getJMSDestination could be null on redeployment of a queue ------------------------------------------------------------------ Key: JBMESSAGING-742 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742 Project: JBoss Messaging Issue Type: Support Patch Affects Versions: 1.0.1.SP2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.2.CR1, 1.0.2.GA, 1.0.1.SP2 -- 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, 3 months

3
27
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2007