[JBoss Messaging] - Re: Set MaxDeliveryAttempts parameter
by mskonda
JBM UserGuide says:
anonymous wrote : The maximum number of delivery attempts can be specified using the attribute DefaultMaxDeliveryAttempts for a global default or individually on a per destination basis.
So, this should work for a individual destination(I have not tried):
| <mbean code="org.jboss.jms.server.destination.TopicService"
| name="jboss.messaging.destination:service=Topic,name=testTopic"
| xmbean-dd="xmdesc/Topic-xmbean.xml">
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <depends>jboss.messaging:service=PostOffice</depends>
| <attribute name="DefaultMaxDeliveryAttempts">3</attribute>
| </mbean>
|
The DefaultMaxDeliveryAttempts will set the delivery retries to three.
Thanks
/Madhu
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031928#4031928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031928
19Â years
[Remoting] - Re: Connection between servers through JNDI?
by ron.sigalï¼ jboss.com
Hi Claudia,
I've been looking at your example, and it raises some interesting issues.
First of all, I think that using two different transports on the same port is just asking for trouble, since each transport has its own expectations about what messages are coming in. So, unless you have a really good reason for using the same port, I would recommend against it.
I expected that when I changed your code to use different ports for the socket and multiplex transports, everything would work fine. It didn't, so I thank you for using two transports on the same port (even though you shouldn't!), since it pointed out a couple of things to be fixed. What is happening, as I think you know, is that the JNDIDetector heartbeat is finding an old reference to a server that no longer exists, trying to ping it, and inadvertently connecting a socket (respectively, multiplex) client invoker to a multiplex (respectively, socket) server invoker. The socket server invoker sees some bytes it doesn't expect, but it shrugs them off. The multiplex server invoker is a little more brittle, so I've made a couple of changes to make it more robust. (Jira issue JBREM-729).
I still found that the example wasn't working quite as I expected, and I made a couple of changes to JNDIDetector as well (Jira issue JBREM-730). In particular, JNDIDetector was slow in discovering its new environment because it was counting to 5 before doing a clean detect. I changed it so that it does a clean detect on the first heartbeat. Also, it had trouble registering its new information with the JNDI server because it was using Context.bind() instead of Context.rebind().
These changes are committed to the CVS repository and will be part of the next release.
Claudia, I'm curious if you're using Remoting in production code, or are you experimenting?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031925#4031925
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031925
19Â years
[Clustering/JBoss] - Re: Farm Deployment with UDP not working
by RedChili
And the same with TRACE logging on:
2007-03-27 09:58:39,421 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] callMethodOnCoordinatorNode(false), objName=FarmMemberService, methodName=farmDeployments
| 2007-03-27 09:58:39,475 TRACE [org.jboss.ha.framework.server.HAPartitionImpl] dests=[192.168.1.105:32790], method_call=FarmMemberService.farmDeployments(), mode=2, timeout=60000
| 2007-03-27 09:58:39,476 TRACE [org.jboss.ha.framework.server.HAPartitionImpl] real_dests=[192.168.1.105:32790]
| 2007-03-27 09:58:39,507 DEBUG [org.jgroups.util.TimeScheduler] Running task org.jgroups.protocols.TP$Bundler$BundlingTimer@7d8e9adf
| 2007-03-27 09:58:39,565 TRACE [org.jboss.ha.framework.server.HAPartitionImpl] responses: [sender=192.168.1.105:32790, retval={farm/kusssdemo.ear=Mon Mar 26 17:14:03 CEST 2007}, received=true, suspected=false]
|
| 2007-03-27 09:58:39,567 DEBUG [org.jboss.ha.framework.server.FarmMemberService] Found 1 farmDeployments responses
| 2007-03-27 09:58:39,568 INFO [org.jboss.ha.framework.server.FarmMemberService] **** pullNewDeployments ****
| 2007-03-27 09:58:39,568 INFO [org.jboss.ha.framework.server.ClusterFileTransfer] Start pull of file kusssdemo.ear from cluster.
| 2007-03-27 09:58:39,568 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] callMethodOnCoordinatorNode(false), objName=org.jboss.ha.framework.server.ClusterFileTransferService, methodName=remotePullOpenFile
| 2007-03-27 09:58:39,568 TRACE [org.jboss.ha.framework.server.HAPartitionImpl] dests=[192.168.1.105:32790], method_call=org.jboss.ha.framework.server.ClusterFileTransferService.remotePullOpenFile(farm/kusssdemo.ear, 192.168.1.106:1099, 192.168.1.106:1099, farm), mode=2, timeout=60000
| ...
| ...
| 2007-03-27 09:59:39,802 TRACE [org.jboss.ha.framework.server.HAPartitionImpl] responses: [sender=192.168.1.105:32790, retval=null, received=false, suspected=false]
|
| 2007-03-27 09:59:39,803 TRACE [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Ignoring non-received response: sender=192.168.1.105:32790, retval=null, received=false, suspected=false
| 2007-03-27 09:59:39,805 ERROR [org.jboss.ha.framework.server.FarmMemberService] org.jboss.ha.framework.server.ClusterFileTransfer$ClusterFileTransferException: Did not receive response from remote machine trying to open file 'farm/kusssdemo.ear'. Check remote machine error log.
|
The timeout 60000 is exactly the time when the "pulling" machine aborts the transfer. Although it's quite unusual that the transfer of a 10Mb file over a LAN takes more than a minute, should I increase this timeout? If yes, where?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031922#4031922
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031922
19Â years