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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Moving state out of ConnectionAspect

by timfox

I see no harm in moving it to the state. There may be some reason it was there in the first place but you'll soon find out if that's the case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977630#3977630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977630

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Moving state out of ConnectionAspect

by clebert.suconic＠jboss.com

On the HA experiment branch, I will be moving some state (maybe all, keeping just some cached properties like ConnectionMetaData) to ConnectionState. I will need that information to recreate the connection during failOver event. It seemed a little bit strange recovering it from the Aspect. I could do it without a problem but I just think it would be better to have that info into ConnectionState instead. Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977629#3977629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977629

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: MessageService and JMS

by mteira

Sorry for triggering questions that fast. I will try to control myself and investigate a little more before asking. I've copied jbpm.cfg.xml to the jbpm/jpdl/jar/src/main/config/jbpm.cfg.xml and changed the message service to use the JMS based one: <service name="message" | factory="org.jbpm.msg.jms.JmsMessageServiceFactoryImpl" /> Now, I'm getting NPE in JmsMessageServiceFactoryImpl openService. It happens at line 49: ConnectionFactory connectionFactory = (ConnectionFactory) initialContext.lookup(connectionFactoryJndiName); I see that the private member connectionFactoryJndiName is initialized to 'null' and there's no method to change it to another value. Is it injected from another place? Is there some code missing here? Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977627#3977627 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977627

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: What binds ClientConnectionDelegate to DelegateSupport.i

by ron_sigal

No "duh". Got me too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977626#3977626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977626

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Issues with shunned node rejoining a cluster

by bstansberry＠jboss.com

Bela can comment better as to whether not getting one last view before you leave is a flaw or intended behavior. Looks like when a DISCONNECT comes down the channel, GMS sends a LEAVE_REQ to the coord, who, before sending out a new view, replies with a LEAVE_RSP. Upon receipt of the LEAVE_RSP, ParticipantGmsImpl sends a DISCONNECT_OK up to the app, and then passses the DISCONNECT down the channel. When the DISCONNECT gets to NAKACK, it puts it into a state where no further messages are passed up. Thus any subsequent view sent by the coord is dropped. Any change to this would have to watch out for breaking this bit in JChannel.up(): case Event.VIEW_CHANGE: | my_view=(View)evt.getArg(); | | // crude solution to bug #775120: if we get our first view *before* the CONNECT_OK, | // we simply set the state to connected | if(connected == false) { | connected=true; | synchronized(connect_mutex) { // bug fix contributed by Chris Wampler (bug #943881) | connect_ok_event_received=true; | connect_mutex.notify(); | } | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977624#3977624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977624

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: What binds ClientConnectionDelegate to DelegateSupport.i

by clebert.suconic＠jboss.com

duh... I should have read the javadoc. I was so blind looking at XML :-) Thanks a lot Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977623#3977623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977623

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: What binds ClientConnectionDelegate to DelegateSupport.i

by ron_sigal

DelegateSupport.init(): | public void init() | { | ((Advised)this)._getInstanceAdvisor().appendInterceptor(this); | | checkMarshallers(); | } | Does this help? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977622#3977622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977622

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - What binds ClientConnectionDelegate to DelegateSupport.invok

by clebert.suconic＠jboss.com

What binds ClientConnectionDelegate to DelegateSupport.invoke? I know how it works, but I was trying to add some stuff for the HA work, but I didn't find anythin XML on aop-messaging-client.xml. Is this because DelegateSupport implements org.jboss.aop.advice.Interceptor and any advice on ClientConnectionDelegate will make it automatically go to DelegateSupport.invoke? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977615#3977615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977615

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Need more metadata for the JARStructure deployer

by scott.stark＠jboss.org

Right now the JARStructure deployer is stumbling around in the dark trying to identify whatever gets passed to it. The two problems I am current seeing are: 1. Its traversing directories it should not, for example, a directory entry in a jar archive. 2. Its not traversing directories it should, for example, a child directory in top level deployment (jbossweb-tomcat6.deployer/jsf-libs). This might be conflicts in the deployment oriented VFS.isArchive attribute, isLeaf, or just bugs, but we need the ability to explicitly define what the structure of a deployment is in terms of deployment contexts and classpath entries via metadata. With such a notion the ear structure deployer would just be a deployer that obtained this metadata via alternate descriptors. The JARStructure deployer would just be java coded logic to produce this metadata. So basically and extension of the ear application.xml structural elements (module and lib dirs) is what I'm thinking of. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977614#3977614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977614

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Issues with shunned node rejoining a cluster

by manik.surtani＠jboss.com

That is really strange - a bug in JGroups? Shouldn't the coord broadcast a new view when someone disconnects, since the cluster membership changes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977612#3977612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977612

19 years, 6 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 October 2006