January 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover refactoring

by clebert.suconic＠jboss.com

I talked to Kabir. We could control instantiation of interceptors by using Factories (witch is a straighforward and documented way), but getInstance is not exposed. So, I requested a feature that will be useful on future releases. http://jira.jboss.org/jira/browse/JBAOP-338 I won't use such feature now as we will stick with delegates or with the muliple valves. (something we will have to decide later), but I think the feature request is valid. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998026#3998026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998026

19 years

1
0
0 / 0

[Design of EJB 3.0] - Re: Component Proposal - Configurable Service Locator

by bill.burke＠jboss.com

Maybe we should allow a pluggable default strategy for determining JNDI bindings? This would be plugged into the server side and would specify how the EJB container should bind to JNDI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998025#3998025 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998025

19 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: decision conditions

by brittm

As stated, It is very un-intuitive and certainly doesn't clearly document what is going on in the decision. I always try to make all of my transition criteria explicit, and can't imagine ever seriously writing a Decision node that would rely on the old behavior. I imagine other developers aren't relying on it either. As Tom mentioned, the docs were wrong and no one even noticed. I would vote for the change. -Britt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998015#3998015 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998015

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover refactoring (Repost)

by clebert.suconic＠jboss.com

I had this conversation in private with Ovidiu, and I wanted to make a public post about this. I'm kind of concerned about the fact we are using multiple valves (instead of a single instance per connection). The way is implemented now, you have a Valve on every descendant of Connection (Sessions, Producers, Consumers and Browsers). When we get a failure, we have to close every single valve before performing a failover, i.e. The lock is not atomic and you have multiple locks. The problem is when you place a try..catch(IOException) on the ValveIntercetor to capture failure exceptions. In cases where you have multiple threads using the same Connection (multiple sessions/threads on the same Connection). As the lock should be aways atomic (close every valve for the failed Connection), you can have multiple Threads trying to close the whole hierarchy of valves. Lets talk in examples: - You have one Connection and 50 Threads/50 Sessions. Suppose all these 50 Threads are communicating at the same time. - We kill the server, all of the 50 threads are going to catch an IOException at the same time. - As all of the 50 threads are going to catch the exception at the same time... All of them are going to close the valve at the same time. Valve close is a loop on the hierarchy: | // from HierarchicalStateSupport | public void closeChildrensValves() throws Exception | { | if (children == null) | { | return; | } | | for(Iterator i = children.iterator(); i.hasNext(); ) | { | HierarchicalState s = (HierarchicalState)i.next(); | ((Valve)s.getDelegate()).closeValve(); | } | } | | public void openChildrensValves() throws Exception | { | if (children == null) | { | return; | } | | for(Iterator i = children.iterator(); i.hasNext(); ) | { | HierarchicalState s = (HierarchicalState)i.next(); | ((Valve)s.getDelegate()).openValve(); | } | } | I belive we should use a single Valve instance, the way it was done before. The only reason for this refactoring was the fact I was using a single instance but using AOP API to install the Valve on the right place with the proper instantiation. This could be refactored in another way such as delegating the Valve to an external object on the ValveAspect (which was going to be renamed to FailureInterceptor). I'm playing with another Branch and I have already refactored it to use a single instance of Valve, and have installed the try...catch(IOException) in place. I'm only using standard XML config. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998012#3998012 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998012

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover refactoring

by clebert.suconic＠jboss.com

I had this conversation in private with Ovidiu, and I wanted to make a public post about this. I'm kind of concerned about the fact we are using multiple valves (instead of a single instance per connection). The way is implemented now, you have a Valve on every descendant of Connection (Sessions, Producers, Consumers and Browsers). When we get a failure, we have to close every single valve before performing a failover, i.e. The lock is not atomic and you have multiple locks. The problem is when you place a try..catch(IOException) on the ValveIntercetor to capture failure exceptions. In cases where you have multiple threads using the same Connection (multiple sessions/threads on the same Connection). As the lock should be aways atomic (close every valve for the failed Connection), you can have multiple Threads trying to close the whole hierarchy of valves. Lets talk in examples: - You have one Connection and 50 Threads/50 Sessions. Suppose all these 50 Threads are communicating at the same time. - We kill the server, all of the 50 threads are going to catch an IOException at the same time. - As all of the 50 threads are going to catch the exception at the same time... All of them are going to close the valve at the same time. Valve close is a loop on the hierarchy: | // from HierarchicalStateSupport | public void closeChildrensValves() throws Exception | { | if (children == null) | { | return; | } | | for(Iterator i = children.iterator(); i.hasNext(); ) | { | HierarchicalState s = (HierarchicalState)i.next(); | ((Valve)s.getDelegate()).closeValve(); | } | } | | public void openChildrensValves() throws Exception | { | if (children == null) | { | return; | } | | for(Iterator i = children.iterator(); i.hasNext(); ) | { | HierarchicalState s = (HierarchicalState)i.next(); | ((Valve)s.getDelegate()).openValve(); | } | } | I belive we should use a single Valve instance, the way it was done before. The only reason for this refactoring was the fact I was using a single instance but using AOP API to install the Valve on the right place with the proper instantiation. This could be refactored in another way such as delegating the Valve to an external object on the ValveAspect (which was going to be renamed to FailureInterceptor). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998012#3998012 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998012

19 years

1
0
0 / 0

[Design of POJO Server] - Re: ObjectModelFactories parsing empty xml elements

by anil.saldhana＠jboss.com

Thanks Scott. That did the trick. I had tried the combination of setValue and newChild but did not figure out returning the parent element. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998011#3998011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998011

19 years

1
0
0 / 0

[Design of EJB 3.0] - Re: Component Proposal - Configurable Service Locator

by ALRubinger

Thanks for your input, Carlo. I've reviewed the relevant parts of the JEE5 Spec (Injection and Client Chapters) and am in the process of putting together my own Application Client to run against JBoss built from TRUNK. Yes, a lot of the issues I'd addressed are handled in the spec. Not covered, and handled by a potential ServiceLocator: * Lookup by interface * Lookup AFTER the main method is called (the spec dictates that injection is done once, via static members, before "main" on the client. What about after?) * @Service injection? How is this currently being handled as a JMX Service Bean is a JBoss-specific extension? And yes, I'd really like to have a client access services on more than one host. This may be outside the discussion of the client container; take into account the case of an EJB with dependencies on other remote EJBs: * Client contacts Application Services as JEE5 Application Client * Application Services depend on some set of Core Services used by many applications - contact via ServiceLocator The core services may be hosted at any number of locations. I'd like to determine how to best address this issue if possible. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998001#3998001 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998001

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover refactoring

by clebert.suconic＠jboss.com

> (and not the other local queues, as it was the case so far) We had routers taking care of this, balancing between local queues and failedover queues. Did you change this policy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997985#3997985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997985

19 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Metadata rewrite

by kabir.khan＠jboss.com

In fact | metaData.getAnnotations() | ends up in its retrieval.getAnnotations() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997981#3997981 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997981

19 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Metadata rewrite

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | However, this does not tell you if there are instance annotations. | What you really need to do is the following (pseudo code): | | | | // Get the instance retrieval for this context | | KernelMetaDataRepository repository = kernel.getMetaDataRepository(); | | MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(context); | | | | if (retrieval.isEmpty() == false) | | // Need an instance proxy | | | I'm not really gettting this... I have found a way (not necessarily the best and final, but it works for my tests) to get hold of the context so I can get hold of the kernel. But for a bean annotated with "real" annotations as | @Test | public class AnnotatedChild extends Base | { | } | | Annotation[] ai = retrieval.retrieveAnnotations().getValue(); | Annotation[] ai2 = retrieval.retrieveLocalAnnotations().getValue(); | Annotation[] anns = metaData.getAnnotations(); | The ai, ai2 and anns all contain the same annotations. I View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3997978#3997978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3997978

19 years

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 January 2007