November 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration

by timfox

"weston.price(a)jboss.com" wrote : Ahhh wait... I see. Sorry, I'm a tool. | | anonymous wrote : | | a) A RuntimeException is thrown from onMessage and ack mode = auto ack or dups ok, retry is immediately attempted (in JBM code). | | | | This is a bit different. I believe in the case of a transacted session the MessageCallbackHandler does nothing correct? It sounds like you are talking about JBM handling non transacted scenarios for DLQ. | | If a RuntimeException is thrown from onMessage and the session is transacted it is ignored as per JMS spec and delivery of the next message continues. Perhaps we should have an option to turn off JCA dlq functionality if we know the provider supports its own? Should this be the default? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986880#3986880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986880

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration

by timfox

"weston.price(a)jboss.com" wrote : | | The DLQ handler is layered with a JBoss specific handler being called first to handle redelivery. First we check for the existence of the JMS_JBOSS_REDELIVERY_LIMIT and JMS_JBOSS_REDELIVERY_COUNT. | You mean JBoss MQ specific? JBoss Messaging doesn't have these properties. "weston.price(a)jboss.com" wrote : | If we can find the count we compare it againts the ActivationSpec property DLQMaxResent. If it's over the limit, the JBoss specific DLQ handles the message. | | If we don't execute the above, the GenericHandler kicks in. We try and check the JMSXDeliveryCount first. If it exists, all is well and we use that as a marker for re-delivery attempts. | | Now, heres the trick :-). | | If that property does not exist, we increment a counter based on the cached ID for that message. So, basically in order: | | JBoss specific | Generic JMSXDeliveryCount | Cached id/count mapping | So you maintain a map of id to count? How long do you keep items in the map for? It could grow pretty big. Also wouldn't survive restart I assume. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986878#3986878 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986878

19 years, 4 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Administration guide for novices

by cyberskunk

Hello all! Is there any guides for novices at administration of jbms? I even cannot understand how one can create new account (after installation finishes)? Is there any hope that Administrative GUI will be available soon? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986872#3986872 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986872

19 years, 4 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Integration issue with the ejb caching

by scott.stark＠jboss.org

Brian raised the following issue about differences in behavior between the legacy in memory tm and JBossTS. I'm posting here in case not everyone watches all forums. http://www.jboss.com/index.html?module=bb&op=modcp&mode=split&t=9505 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986869#3986869 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986869

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration

by weston.price＠jboss.com

Ahhh wait... I see. Sorry, I'm a tool. anonymous wrote : | a) A RuntimeException is thrown from onMessage and ack mode = auto ack or dups ok, retry is immediately attempted (in JBM code). | anonymous wrote : | | | | This is a bit different. I believe in the case of a transacted session the MessageCallbackHandler does nothing correct? It sounds like you are talking about JBM handling non transacted scenarios for DLQ. | | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986867#3986867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986867

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Mock JMS Provider

by scott.stark＠jboss.org

Its easy to create a simple in memory jndi implementation for use in this type of setup. I did this a part of the jndi aspect testing in the mc. We should probably add these simple mock objects to the jboss test project for reuse. Or are you talking about something else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986866#3986866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986866

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: LDAP Support expectations

by bvogt

Is there some information, how to setup and execute the tests? Thanks in advance, Burkhard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986864#3986864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986864

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover (Repost)

by clebert.suconic＠jboss.com

Tim wrote : ...why you think you need a ClusteredConnectionFactory... - How would you as an user, decide if you want to use an HAConnection or not? - The ClientConnectinFactory which is dealing with HA, is being called ClusteredClientConnectionFactory, and it aggregates ClientConnectinFactory[]. I will round robbing between the array of child factories. Tim wrote : ...and why you need to replicate more than the locatorURI? ClientConnectionFactory has also an equivalent ServerConnectionFactoryEndpoint, right? Looking at properties from ClientConnectionFactoryDelegate: | //... from superClass DelegateSupport: | protected int id; | | //... from the class itself | | protected String serverLocatorURI; | protected Version serverVersion; | protected int serverID; | protected boolean clientPing; | I would need to replicate at least the LocatorURI and the serverID and DelegateSupport::id, assuming serverVersion and clientPing won't never change. Well... as I had to store almost everything, why not to take this into a real instance of ClientConnectionFactoryDelegate? It made much more sense for me. Anyway... today I'm going to change ClusteredConnectionFactoryClient a lot today. I had created two classes: One ClusteredClientConnectionFactoryDelegateServer and another ClusteredConnectionFactoryClient. The server version was supposed to use serialization replaceObject with the Client version updating the list of server from one PostOffice. This didn't work of course.. I will change the PostOffice to re-register the ClusteredConnectionFactory when the View changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986862#3986862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986862

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by clebert.suconic＠jboss.com

Tim wrote : ...why you think you need a ClusteredConnectionFactory... - How would you as an user, decide if you want to use an HAConnection or not? - The ClientConnectinFactory which is dealing with HA, is being called ClusteredClientConnectionFactory, and it aggregates ClientConnectinFactory[]. I will round robbing between the array of child factories. Tim wrote : ...and why you need to replicate more than the locatorURI? ClientConnectionFactory has also an equivalent ServerConnectionFactoryEndpoint, right? Looking at properties from ClientConnectionFactoryDelegate: | //... from superClass DelegateSupport: | protected int id; | | //... from the class itself | | protected String serverLocatorURI; | protected Version serverVersion; | protected int serverID; | protected boolean clientPing; | I would need to replicate at least the LocatorURI and the serverID and DelegateSupport::id, assuming serverVersion and clientPing. Well... as I had to store almost everything, why not to take this into a real instance of ClientConnectionFactoryDelegate? It made much more sense for me. Anyway... today I'm going to change ClusteredConnectionFactoryClient a lot today. I had created two classes: One ClusteredClientConnectionFactoryDelegateServer and another ClusteredConnectionFactoryClient. The server version was supposed to use serialization replaceObject with the Client version updating the list of server from one PostOffice. This didn't work of course.. I will change the PostOffice to re-register the ClusteredConnectionFactory when the View changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986862#3986862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986862

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-126 -- JMS expiration

by weston.price＠jboss.com

anonymous wrote : | JBM itself needs it's own DLQ logic since we won't always have JCA. E.g. in the standalone server case. | Yep. Makes sense. So I wasn't too far off base. anonymous wrote : | BTW I'm unclear as to how you keep track of how many times delivery has been attempted in the JCA layer? JMSXDeliveryCount is an optional property not supported by all messaging systems, so if you rely on that your code won't necessary work with other messaging systems. | anonymous wrote : | | | | The DLQ handler is layered with a JBoss specific handler being called first to handle redelivery. First we check for the existence of the JMS_JBOSS_REDELIVERY_LIMIT and JMS_JBOSS_REDELIVERY_COUNT. If we can find the count we compare it againts the ActivationSpec property DLQMaxResent. If it's over the limit, the JBoss specific DLQ handles the message. | | | | If we don't execute the above, the GenericHandler kicks in. We try and check the JMSXDeliveryCount first. If it exists, all is well and we use that as a marker for re-delivery attempts. | | | | Now, heres the trick :-). | | | | If that property does not exist, we increment a counter based on the cached ID for that message. So, basically in order: | | | | JBoss specific | | Generic JMSXDeliveryCount | | Cached id/count mapping | | | | Interestingly enough the two conditions you specify: | | | | anonymous wrote : | | | a) A RuntimeException is thrown from onMessage and ack mode = auto ack or dups ok, retry is immediately attempted (in JBM code). | | | | | | b) Session gets closed before acking messages so messages are nacked back to the destination. | | | anonymous wrote : | | | | | | | | should actually never occur in JCA land for the following reasons: | | | | | | | | a) I never propogate a RuntimeException from onMessage. Effectively I trap it and deal with it locally via Transaction demarcation. | | | | | | | | b)Sessions are never closed during delivery, only in the case where they have reached an idle timeout, or the adapter itself is being stopped. | | | | | | | | So, effectively it sounds like I am 'jumping in the way' of JBM DLQ. Of course you do redeliver in the case of a commit/rollback on either an XA or local JMS transaction but in this case the JCA DLQ handler would grab it because it is not one of the conditions above. At least that's how I have it in my head. | | | | | | | | | | | | | | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986861#3986861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986861

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-dev-forums November 2006