January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-527) JBoss Messaging should support JMSXDeliveryCount

by Joel Lindheimer (JIRA)

JBoss Messaging should support JMSXDeliveryCount ------------------------------------------------- Key: JBMESSAGING-527 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-527 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.0.1.CR4 Environment: All Reporter: Joel Lindheimer Assigned To: Ovidiu Feodorov Joel: Here is an excerpt from theserverside which sums up the retry concept within a transaction well: http://www.theserverside.com/tt/articles/content/JMSArchitecture/JMSAppli... For point-to-point messaging, when a transaction reads a message, the message becomes available to the transaction, but does not get physically removed from the destination at that time; instead, the messaging system leaves the message on the destination but does not allow other transactions to see it. When the transaction commits, the message is completely removed from the destination; however, if the transaction rolls back, the message stays on the destination and is now allowed to be read by other transactions. Ovidiu: Right. This is what Messaging does it. Though, to be 100% technically accurate, what it does is actually transacting acknowledgments. The message becomes available to the transaction, and it's the acknowledgment that is sent back to the channel in a transactional context. The acknowledgment is delivered to the channel (and the message removed from the channel) only when transaction commits. This allows for a powerful feature called replay. Replay is the ability to retry the transaction after a rollback. The danger here is you can get caught in an infinite loop trying to replay the transaction. However, JMS systems can make use of the re-delivered count field on the message descriptor. Here, one can determine how many times the message has been re-delivered to a consumer and allow one to stop processing the message. We're actually not supporting JMSXDeliveryCount yet, you're right here. The spec says it's optional. If it's important for you, just log a JIRA feature request, and we'll do it, subject to resource availability :). Joel: Thanks Ovidiu, JMSXDeliveryCount is definitely a very high priority for us. With the rapid growing adoption of MDP use I imagine that I will be something that is also in high demand for the community at large. Furthermore, most JMS vendors support this behavior, so it probably makes sense for JBoss to put it on the roadmap. -- 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, 4 months

3
3
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-122) Implement the stats and monitoring MBean operations on destinations

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-122?page=all ] Tim Fox closed JBMESSAGING-122. ------------------------------- Fix Version/s: (was: 1.2.1) 1.2.0.Beta2 Resolution: Done > Implement the stats and monitoring MBean operations on destinations > ------------------------------------------------------------------- > > Key: JBMESSAGING-122 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-122 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Configuration and Management > Affects Versions: 1.0.0 alpha PR1 (non-clustered) > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.0.Beta2 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Implement all the statistics and monitoring MBean operations on topics and queues, to bring up to level of functionality of JBossMQ. > E.g. message counts, message lists, subscription lists etc. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-122) Implement the stats and monitoring MBean operations on destinations

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-122?page=all ] Tim Fox reopened JBMESSAGING-122: --------------------------------- > Implement the stats and monitoring MBean operations on destinations > ------------------------------------------------------------------- > > Key: JBMESSAGING-122 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-122 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Configuration and Management > Affects Versions: 1.0.0 alpha PR1 (non-clustered) > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.0.Beta2 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Implement all the statistics and monitoring MBean operations on topics and queues, to bring up to level of functionality of JBossMQ. > E.g. message counts, message lists, subscription lists etc. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-122) Implement the stats and monitoring MBean operations on destinations

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-122?page=all ] Tim Fox closed JBMESSAGING-122. ------------------------------- Assignee: Tim Fox Resolution: Done > Implement the stats and monitoring MBean operations on destinations > ------------------------------------------------------------------- > > Key: JBMESSAGING-122 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-122 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Configuration and Management > Affects Versions: 1.0.0 alpha PR1 (non-clustered) > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Implement all the statistics and monitoring MBean operations on topics and queues, to bring up to level of functionality of JBossMQ. > E.g. message counts, message lists, subscription lists etc. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-560) Support all JBossMQ equivalent JMX functionality

by Tim Fox (JIRA)

Support all JBossMQ equivalent JMX functionality ------------------------------------------------ Key: JBMESSAGING-560 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-560 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.0.Beta1 For 1.2 we need to ensure we support the same or equivalent set of management functionality as JBoss MQ. -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-716) Same message multiple times in DLQ/Expiry Queue

by Tim Fox (JIRA)

Same message multiple times in DLQ/Expiry Queue ----------------------------------------------- Key: JBMESSAGING-716 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-716 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta2 The same message might end up in the a DLQ or expiry queue multiple times, e.g. if a message is sent to a topic with multiple subscriptions, then exceeds max delivery attempts on some but not otheres. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-127) Delayed delivery, redelivery count and pluggable expiration behavior

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-127?page=all ] Tim Fox closed JBMESSAGING-127. ------------------------------- Resolution: Done > Delayed delivery, redelivery count and pluggable expiration behavior > -------------------------------------------------------------------- > > Key: JBMESSAGING-127 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-127 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core, JMS Facade > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.0.Beta2 > > Original Estimate: 1 week, 2 days > Remaining Estimate: 1 week, 2 days > -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-344) jbossesb-1.0.xsd accepts a list of listeners per service. The listeners themselves (message and gateways) only take one EPR.

by Esteban Schifman (JIRA)

jbossesb-1.0.xsd accepts a list of listeners per service. The listeners themselves (message and gateways) only take one EPR. ----------------------------------------------------------------------------------------------------------------------------- Key: JBESB-344 URL: http://jira.jboss.com/jira/browse/JBESB-344 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.0 CR2 Reporter: Esteban Schifman Assigned To: Kurt Stam Fix For: 4.0 CR1 The jbossesb-1.0.xsd accepts a list of listeners for each service. The xsd compliant xml configuration files will translate into 'old style' rosetta xml configuration files, that only take one EPR per listener. The translation process should take care of repeating the listener configuration attributes and child elements, so that each listener has one and only one EPR. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-355) STREAMING_STATE_TRANSFER doesn't work without FLUSH

by Bela Ban (JIRA)

STREAMING_STATE_TRANSFER doesn't work without FLUSH --------------------------------------------------- Key: JGRP-355 URL: http://jira.jboss.com/jira/browse/JGRP-355 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.5 STREAMING_STATE_TRANSFER should work *without* FLUSH being required. STREAMING_STATE_TRANSFER.use_flush should be *overridden* and set to false if FLUSH is not present <config> <TCP_NIO recv_buf_size="20000000" send_buf_size="640000" loopback="false" discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="false" down_thread="false" up_thread="false" enable_bundling="true" start_port="7800" use_send_queues="false" sock_conn_timeout="300" skip_suspected_members="true" reader_threads="8" writer_threads="8" processor_threads="8" processor_minThreads="8" processor_maxThreads="8" processor_queueSize="100" processor_keepAliveTime="-1"/> <MPING timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/> <MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/> <FD_SOCK down_thread="false" up_thread="false"/> <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" down_thread="false" up_thread="false" discard_delivered_msgs="true"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false" join_retry_timeout="2000" shun="true" view_bundling="true"/> <FC max_credits="2000000" down_thread="false" up_thread="false" min_threshold="0.10"/> <FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> <pbcast.STREAMING_STATE_TRANSFER down_thread="false" up_thread="false" use_flush="true" use_reading_thread="true"/>   </config> -- 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, 4 months

2
5
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-406) Improve handling of method calls that are queued during region activation

by Vladimir Blagojevic (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-406?page=all ] Vladimir Blagojevic resolved JBCACHE-406. ----------------------------------------- Resolution: Done Fix Version/s: (was: 2.1.0.GA) 2.0.0.GA With introduction of FLUSH in all JBC state transfers this task becomes obsolete. > Improve handling of method calls that are queued during region activation > ------------------------------------------------------------------------- > > Key: JBCACHE-406 > URL: http://jira.jboss.com/jira/browse/JBCACHE-406 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 1.2.4SP1, 1.2.4 > Reporter: Brian Stansberry > Assigned To: Vladimir Blagojevic > Fix For: 2.0.0.GA > > > During a call to activateRegion(), any incoming replication messages related to the relevant region are queued (i.e. stored in a list) and then invoked once the region's state has been received and integrated. Doing this, in the case of prepare() messages, violates transactional integrity, since the activating cache responds positively after queuing the prepare(), and only finds out later whether the prepare() can actually succeed. So, we need to optimize the queuing process to give the greatest likelihood that any received prepare calls will in fact succeed. Fundamentally, we want to arrange the queue so that any commit() message immediately follows its related prepare, thus reducing the likelihood that a subsequent prepare will not be able to succeed due to conflicts with the preceding prepare's locks. > When a new commit()/rollback method call is received: > 1) Iterator through the existing queued calls, looking for a prepare() associated with the same gtx. > 2) If a prepare is found, and the new message is a commit, place the commit in the queue immediately after the prepare. > 3) If a prepare is found, and the new message is a rollback, remove the prepare from the queue. > 4) If no prepare is found, discard the commit or rollback; there is no point later executing a commit/rollback if the prepare has not been executed. -- 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, 4 months

1
0
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 January 2007