[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
[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"/>
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/ -->
<!--pbcast.FLUSH down_thread="false" up_thread="false"/-->
</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
[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