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

[Design of JBoss Web Services] - Re: ws-eventing clustering problem

by maeste

"jason.greene(a)jboss.com" wrote : A better option would be to synchronize state using JBossCache, then all of the hard work is done for you. Even though you | -Jason Is this suggestion referred to my proposal or Heiko's one? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989729#3989729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989729

17 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing clustering problem

by maeste

"heiko.braun(a)jboss.com" wrote : | OK. So far you are right. | The load balancer doesn't know about the addressing porperties. | But JBossWS does. Currently we can dispatch beased on WS-Addressing properties. I think this should be extended to fully support virtual addresses within a cluster topology. | Ok, right. I have to read something more on ws-addressing "heiko.braun(a)jboss.com" wrote : | IMO this problem is not related to WS-Eventing in particular. | It's a WS-Addressing problem that occurs in any cluster toplogy and should addressed there. | 100% agree "heiko.braun(a)jboss.com" wrote : | Therefore i'd favor a common solution that's build around WS-Addressing and thus supports any WS-* extension which is composed with WSA. | Of course it's the best approach...I'm going to have a deeper look to WS specs. Just one more question: it seems becoming something more widespread modification. Can I go on, or do you prefer a committer working on that? And if yes, is it better it will go in jbossws 2.0? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989727#3989727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989727

17 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Page navigational state update

by julien＠jboss.com

yes nobody gave me feedback :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989725#3989725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989725

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by kabir.khan＠jboss.com

"bstansberry(a)jboss.com" wrote : I assume this means the default UCL for the deploy dir also loads the jars in /server/all/lib (where jboss-cache.jar and jgroups.jar are located.) I came to the same conclusion a few weeks ago. jboss/lib - seems to be the bootstrap jboss/server/xxx/lib - a UCL View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989723#3989723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989723

17 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing clustering problem

by jason.greene＠jboss.com

A better option would be to synchronize state using JBossCache, then all of the hard work is done for you. Even though you can run JBossCache in local mode, I think having some kind of abstracted state store that supports in-memory and cache would be the way to go. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989721#3989721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989721

17 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing clustering problem

by heiko.braun＠jboss.com

Your approach is perfectly valid. I just think that the problem is not directly related to WS-Eventing. It's more an addressing problem. Two simple use cases: 1.) client send's subscribe request 1.1 ) loadbalancer points it to node A 1.3) event source on node A addresses the subscription manager (node B) HA-Singleton through HA-JNDI 1.4) event source sends SM EPR (node B) to client 2.) client send's renew 2.1) loadbalancer points it to node C 2.3) EXCEPTION: no subscription manager on node C OK. So far you are right. The load balancer doesn't know about the addressing porperties. But JBossWS does. Currently we can dispatch beased on WS-Addressing properties. I think this should be extended to fully support virtual addresses within a cluster topology. IMO this problem is not related to WS-Eventing in particular. It's a WS-Addressing problem that occurs in any cluster toplogy and should addressed there. Therefore i'd favor a common solution that's build around WS-Addressing and thus supports any WS-* extension which is composed with WSA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989720#3989720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989720

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by bstansberry＠jboss.com

Not in the AS if a scoped classloader is used, i.e.: 1) Cache is deployed from an ear/sar with a loader-repository configured 2) (I'm pretty sure) if cache is deployed from a webapp (e.g. a ServletContextListener does it at startup.) If region-based marshalling isn't used, the classloader JBC uses to deserialize messages is the one that loaded JBC itself. In the above cases, this classloader is a parent to the application's classloader, and thus can't see classes loaded by the parent classloader. I mistakenly believed this would also cause problems with things deployed directly in /deploy (e.g. an ear without its own loader-repository) but experiments today show this is not the case. I assume this means the default UCL for the deploy dir also loads the jars in /server/all/lib (where jboss-cache.jar and jgroups.jar are located.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989719#3989719 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989719

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by max.andersen＠jboss.com

yes, if the JBC instance is solely owned by one application then it would work as such. But is that actually what happens today ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989700#3989700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989700

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Default classloader for deserialization

by manik.surtani＠jboss.com

Brian actually speaks about (correct me if I am wrong) a custom usage where each app starts it's own cache. For 'shared' caches, such as http session repl and the like, a single cache is shared across webapps and using regions is the default here. But using regions has it's own overhead and in the case where there is only one app using the cache, the default TCCL used should be the one that started the cache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989699#3989699 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989699

17 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing clustering problem

by maeste

Yes, it makes sense for me., it seems a good solution for cluster environment where all real server is accessible directly. In our environment (and I think is a widely used solution) we have a load balancer router in front of our real server. Clients call virtual address/port and Linux Virtual Server NAT the tcp connection to the less used real server. I think in this situation isn't possible to use your ws-Addressing proposed solution because real server can't be reached directly by client's http connection. What I was proposing is a distributed multiple SubscriptionManager and EventDispatcher synchronizing with jGroups. What's wrong in this solution? I hope I was sufficient clear, let me know if my mind seems a farm pond full of frogs :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989697#3989697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989697

17 years, 10 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 November 2006