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

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

by bstansberry＠jboss.com

Very quick reply; I'll have to think more... 1) Probably relatively little of the *existing* AS server side code. The AS code is based around the DistributedReplicantManager interface, the implementation of which uses HAPartition, which is built on an RpcDispatcher. In AS 5 it may use JBoss Cache. Neither matches what you're doing very well. The interface and some concepts probably should be reused, but we'd need a new implementation. The stuff that should be reused is the interceptor model. The AS currently has two interceptor models; the old pre-aop model used by most clustered services and the Remoting- and aop-based EJB3 model. Tom Elrod is working to come up with a unification of the two, based on the EJB3 one. Clearly it's best if Messaging can use the same stuff. I'll look at the EJB3 stuff this weekend and reply with thoughts and how to move forward. 2) The JGroups view can't be used directly, as a JGroups Address is not suitable for use as a Remoting InvokerLocator. At minimum a different port. Quite possibly a different IP address (e.g. client connections use a different NIC than clustering traffic.) I think the thing to do is something like adding another Request type where a server publishes its InvokerLocator(s); the rest of the cluster maintains a map of that data. That's basically the DistributedReplicantManager concept. 3) That's tricky. The AS' model for telling the client about the cluster topology is to piggy-back any new topology on the response to a client request. So, client doesn't know new topology until it successfully makes a request, possibly after a failover. So, we can't count on the client and server making the same decision (e.g. failover to next node in list) because the "list" may be different on client and server. Perhaps an approach where the client fails over to anyone, but if the server isn't the appropriate one it communicates that back to the client, along with the updated topology and info as to who the failover server should be. Stupid question: why does the client need to fail over to a particular server? The failover server needs to do work to recover persistent messages from the store, but once it's done that, aren't they available to a client connecting to any server? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976667#3976667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976667

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience

by mark.little＠jboss.com

"tfennelly" wrote : | The relative paths issue still exists - we can tackle that next week :-) I've also identified a few other issues/inconsistencies that I think need looking at - the notification methods are a bit dodge I think, the process(File) is dodge too now that we've got the Message types. | I think that given the overall Rosetta architecture, what's there now in temrs of Messages is good enough until dispatchers go in to the next release. There are more important areas to concentrate on IMO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976666#3976666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976666

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience

by tfennelly

OK, so I think I've sorted out a fair few of the issues with the trailblazer, it's configuration etc. Firstly, there was a multitude of issues with it from all sorts of sources - which sorta proves that we're not testing it enough after making changes to the code... hint hint ;-) So: 1. The config is cached, so now you get what you entered last time as the defaults. 2. Hopefully the slashes issue is a thing of the past now too - we catch the AS home param supplied on input and do a "fixup" on it before using it. 3. The "ant configure" task does everything for you now (caveat: unless there's something else I don't know about), so you don't have to remember (or know about) to deploy the loanbroker war file to the AS. I only realised yesterday that I was supposd to be doing this!! The relative paths issue still exists - we can tackle that next week :-) I've also identified a few other issues/inconsistencies that I think need looking at - the notification methods are a bit dodge I think, the process(File) is dodge too now that we've got the Message types. If people could do an update and give it a whirl it would be great. Lets see how long we can keep it working this tim ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976662#3976662 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976662

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests

by ovidiu.feodorov＠jboss.com

Adrian, integration with MC and all these grandiose plans are all fine, but don't you think it would me more practical to start with an initial first small step: separation of "generic" JMS tests from JBossMQ-specific functional tests, and making sure that the integration tests work with both MQ and Messaging using the simplest possbile refactoring that Richard suggested? The net gain is that we have Messaging qualified for JBossAS ASAP, and nothing would preclude Richard (or somebody else) to build later in top of that, so eventually we reach the nirvana of integration tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976660#3976660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976660

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache physical POJO field mapping and region

by bstansberry＠jboss.com

"ben.wang(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose. | | I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API? The specific use case it the root of the region is the root of the webapp; the children are the sessions. A call to getChildrenNames() provides the ids of all the sessions in the cache. That's the specific case, but I think it's a general problem. Node higher in the tree defines some category; children represent specific instances. I think a general solution of some sort (e.g. like Elias mentions) is appropriate. As a sophisticated user I can of course get around this by removing _JBossInternal_ from the set. But that's a hack. You could provide some kind of PojoCache function to replace the getChildrenNames() call, but the usage here is really a plain cache usage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976637#3976637 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976637

19 years, 6 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Interceptor medasata issue

by fakeer

hey thomas, can you tell me how you configured your client and server side interceptors to work with ejb3? did you start another thread elsewhere regarding this problem? or clebert can you point me to any documentation on how to configure this stuff (what xmls etc.) thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976635#3976635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976635

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: refactoring visitor in VFS

by bill.burke＠jboss.com

Still, you get a lot more flexibility on whether or not to recurse by letting the visitor decide what the parameters to recurse or not to recurse are. That's traditionally how the visitor pattern works. The visitor decides how to recurse. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976630#3976630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976630

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: missing groups for role assignments

by julien＠jboss.com

so basically you want to have group of security roles ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976628#3976628 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976628

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: refactoring visitor in VFS

by adrian＠jboss.org

But in the context of the hypothetical classpath visitor, you wouldn't even see the subdelpoyment to return false on. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976624#3976624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976624

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Jars for Drool integration examples

by tom.baeyens＠jboss.com

jeff, please make sure that only the local example has a get.dependencies target for these libraries. also the local build file (or the local properties file) should have the properties that point to the remote and local repository files. you might do this in the same format as the overall build. there are other integrations as well that require many dependent libs (e.g. jackrabbit). i don't want to have to fetch *all* of those dependencies in for the overall build. I don't not want those libs in the standard eclipse classpath. If you keep to that, you can just commit that. is that ok for you ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976622#3976622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976622

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