May 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Order of Deliveries between Backup and Live Node

by clebert.suconic＠jboss.com

Another version of the second diagram with more details: View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230160#4230160 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230160

16 years, 11 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Unexpected behaviour in PER_CLASS_JOINPOINT aspect facto

by kabir.khan＠jboss.com

I have made it cache [url]https://jira.jboss.org/jira/browse/JBMICROCONT-427 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230159#4230159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230159

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Order of Deliveries between Backup and Live Node

by clebert.suconic＠jboss.com

I have been investigating https://jira.jboss.org/jira/browse/JBMESSAGING-1558 and this is what I have found so far: On a regular flow, this is what happens when messages are delivered to Consumers: [img]https://jira.jboss.org/jira/secure/attachment/12326748/diagram1.png[/img] References are aways backed up before delivered to Consumers. This process is totally async. We will fire the replication and wait the callback, and when it's backed up, we will deliver messages to the consumers. However if the delivering messages are canceled for any reason. (that includes close, or rollback): [img]https://jira.jboss.org/jira/secure/attachment/12326746/diagram2.png[/img] QueueImpl::deliverAsync (or DeliverRunner->deliver) will remove references of the top of the list on independently of the threads being used on the repplication. As a result it may remove the message on LiveNode and when the message is repplicated the backup will have a different element on the top list. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230133#4230133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230133

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Naming, @JNDI and OnDemand

by alesj

"alesj" wrote : | (2) Why do we have two diff impls of AbstractJNDILifecycleCallback, when they do exactly the same? | Stupid question, disregard it. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230104#4230104 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230104

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - JmsConnectionPool: Allowing control over the number of Sessi

by tfennelly

The current implementation of the JmsConnectionPool is designed to use a single JMS Connection and from it, create all JMS Session instances for the Session pool. Not all JMS Providers support an unlimmited number of JMS Sessions per Connection. IBM Websphere MQ (WMQ) is one example if this, but there are probably others too, so we are treating this as a general issue with our JmsConnectionPool. Therefore, we need to modify the JmsConnectionPool code to support this. I've been trying in vain to reproduce this on WMQ, so in an effort to make some sort of progress, I decided to forget about WMQ for now. I've reproduced the issue using mocks and we can come back to WMQ at a later date. There are 2 general solutions as I see it... Common to both solutions would be a pool of JMS Connections. For a provider that supports an "unlimited" (not to be taken literally ;) ) number of sessions/connection, this pool would ever only have a single Connection and all Sessions would be created from this. Then, I think we can manage the relationship between this pool and the sessions created from its connections in one of two ways (remember - general approach): 1. Maintain a Session Pool per Connection on in the Connection Pool. 2. Maintain a single Session Pool for all Connections in the Connection Pool. I would need to play with the code a little, but I think option #2 above might be the least intrusive on the JmsConnectionPool codebase. We can associate each Session with its owner Connection via the JmsSession class (part of the pooling code). Then we can manage adding sessions to the central pool by locating an existing Connection from the Connection Pool (one that can still create a Session i.e. has not hit its max session count), or by creating a new Connection in the Pool. As I said... I really need to play with the code a little now, so this post is just to let people get an idea of what I'm thinking. If people have any comments, feel free to share them. Otherwise I'll post back here in a little while :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230103#4230103 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230103

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Naming, @JNDI and OnDemand

by alesj

"alesj" wrote : | What to do? :-) | (a) have OnDemand stay in Pre_Install | PreInstall is too soon, as we don't have the MetaData fully populated till then. e.g. we only know how to match @JNDI with AOP lifecycle in Described state While moving aop lifecycle to describe | <lifecycle-describe xmlns="urn:jboss:aop-beans:1.0" | name="JNDIPreInstallAdvice" | class="org.jboss.naming.microcontainer.JNDIOnDemandLifecycleCallback" | classes="@org.jboss.naming.microcontainer.JNDI"> | </lifecycle-describe> | and this hack | KernelControllerContext context = getControllerContext("Test", ControllerState.NOT_INSTALLED); | change(context, ControllerState.DESCRIBED); | assertBinding("Test", "Hello"); | then the OnDemand test works. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230087#4230087 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230087

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Configuration Errors

by david.lloyd＠jboss.com

I don't see how that might help though - the binding occurs with JAXB so by the time a deployer gets ahold of the data, it's already in an object model, so any location info would have already been lost. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230083#4230083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230083

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Naming, @JNDI and OnDemand

by alesj

WRT - initial ml post: http://lists.jboss.org/pipermail/jboss-development/2008-November/012997.html - the latest ml post (where Adrian moves his code to svn): http://lists.jboss.org/pipermail/jboss-development/2009-May/014341.html A few questions after checking the code. (1) | /** | * JNDI. | * | * TODO move to AS integration project | * @author <a href="adrian(a)jboss.com">Adrian Brock</a> | Where exactly would you wanna move this? What should we do with "duplicated" @JndiBinding in AOP-MC-int? (2) Why do we have two diff impls AbstractJNDILifecycleCallback, when they do exactly the same? (3) Basically the OnDemand test is completely broken. :-) By default it was passed an AUTOMATIC mode, which meant it was never really On_Demand. Once I fixed this, there is this problem with @JNDI and On_Demand. @JNDI matches AOP lifecycle, which needs a _real_ state (not Not_Installed) in order to kick in. Whereas the OnDemand beans just stay at Not_Installed, meaning they will not get "intercepted" by @JNDI lifecycle hooks until they move fwd. What to do? :-) (a) have OnDemand stay in Pre_Install (b) add extra Not_Installed AOP lifecycle hook View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230081#4230081 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230081

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Imposed ordering of elements

by kabir.khan＠jboss.com

I got this working with a bit of help from Ales. I'll commit the changes against https://jira.jboss.org/jira/browse/JBMICROCONT-426 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230079#4230079 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230079

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Imposed ordering of elements

by alex.loubyansky＠jboss.com

As I mentioned before, @XmlType(propOrder= {}) binds to a model group all (http://www.w3.org/TR/xmlschema-1/#Model_Groups) which can contain only elements (not sequences or choices). Interceptors in your case will be bound to a repeatable choice. See javadoc for XmlElements. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230064#4230064 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230064

16 years, 11 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 May 2009