September 2006 - jboss-dev-forums

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XARecovery - MQ/Messaging merge

by mskonda

"timfox" wrote : Let me just clarify what you're doing: | | Have I got this right? | Yes. anonymous wrote : | [BTW recover() can be called on the XAResource *after* the channel has been loaded - so you can't rely on channel.load() loading all the recovered data.] | Recovery takes place once every one has settled - the messaging server, application server etc. Infact, there's a time lag before any recovery kicks in. anonymous wrote : | How you verified that the recovered data is reloaded when the channel is loaded? | I have checked the database to see the rows in relevant tables. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969469#3969469 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969469

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XARecovery - MQ/Messaging merge

by timfox

Let me just clarify what you're doing: 1. You have a durable subscriber on a destination. 2. You send a messsage to the sub in a global transaction 3. The tx is committed. 4. Prepare completes ok. 5. You force a server "crash". 6. On recovery of the server, the database looks ok (it is in state C). 7. Try to receive() message using a consumer on the subscription and you cannot receive message. Have I got this right? [BTW recover() can be called on the XAResource *after* the channel has been loaded - so you can't rely on channel.load() loading all the recovered data.] How you verified that the recovered data is reloaded when the channel is loaded? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969467#3969467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969467

17 years, 8 months

1
0
0 / 0

[Design of JBoss Labs] - Re: New properties for shotoku.properties

by damon.sicore＠jboss.com

What happens when a thread doesn't terminate for a specific resource? Will another thread be used for that same resource the next time around? In other words, will we eventually lose all threads to updating a resource that hangs forever? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969463#3969463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969463

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XARecovery - MQ/Messaging merge

by mskonda

The recovery (almost) is in place ? however, I have a test failing. I need your input in this case. the scenario is given below: I am using application sever as test base (test case works fine when I use statndalon recovery manager). - I have a durable subscriber on a destination. - I have prepared a transaction which I expect to be recovered when the server is back up. So, when the server is back, the recovery is fine ? that is, the transaction is committed (and the row is deleted) and the message reference state changed to ?C? from ?+?. However, the durable subscriber doesn?t receive this message for ever! The only(main) difference I see before killing and after restarting up the server is the ChannelSupport?s load method being called for resetting the channel state leaving the 'Loaded' column from ?Y? (before restart) to ?N? (after restart). Do you think this has something to do with the delivery to the client? Let me know if I am missing any obvious. Thanks Madhu View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969462#3969462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969462

17 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Registry Design

by mark.little＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : Good, I'm glad that's clear :-) | | It may be that I have misunderstood the discussion but my concerns were the following | - talk of defining the interface in SOAP and embedding in a servlet container | - talk of clustering facades for non clustered implementations | | While both of these may be important from an implementation and deployment perspective, neither is relevant to the service interface being defined. | | The priority for now is to work out the requirements for this interface and, while we should keep the implementation details in mind, these details should not distract us from the specification of the interface. Agreed. Talking about SOAP and clustering is immediately taking us down the implementation route. Although they are relevant to the topic (Registry Design), I think it would be easier if we tried to keep each topic narrowly focussed. We already had a discussion around the API, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81236 where we agreed to use JAX-R. We shouldn't be thinking about implementing a registry at this stage: believe me, it'll take more time than we have available to us for the first GA. Plus, it's a product/project in its own right (there are several companies whose sole reason to exist is to sell a registry). Where I think we should be going with this is: given we'll use JAX-R for now, what does that mean for the ESB? What JAX-R implementations are out there that we can use? Do we have to implement our own JAX-R system (hopefully not). Assuming we have JAX-R support, what existing registry implementations can be tied into it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969415#3969415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969415

17 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Registry Design

by mark.little＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : Clustering is an implementation detail and is not relevant to the interface, neither is SOAP. | | The interface must define a clean, functional API that can be backed by any implementation providing similar functionality. +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969411#3969411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969411

17 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Registry Design

by mark.little＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : Clustering, implementation and transport technology should not be reflected in the interface that you are defining. The intention is to define an abstraction that can be mapped onto any registry implementation using any transport. | Yup. The interface to the registry should be via JAX-R. I don't see any good reason to define our own interface, since JAX-R does not preclude different (non-UDDI) implementations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969410#3969410 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969410

17 years, 8 months

1
0
0 / 0

[Design of JBoss Labs] - Re: New properties for shotoku.properties

by adamw

Hello, new property to add: | shotoku.updatethread.count = 10 | -- Adam View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969407#3969407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969407

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal 2.4.1

by julien＠jboss.com

For the 2.4.1 work : 1/ work is first developped in trunk (2.6). 2/ work is the backported to 2.4.1 in a second time. the goal is to not have prototype work in 2.6. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969390#3969390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969390

17 years, 8 months

1
0
0 / 0

[Design of JBossXB] - Re: GenericObjectModelProvider not setting attributes in XML

by info＠connext.co.za

Good Day, Thanks it works!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969368#3969368 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969368

17 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006