November 2006 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: ws-eventing: event notification failure

by heiko.braun＠jboss.com

cool, thanks. i will take care that it get's included in 1.0.5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990129#3990129 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990129

17 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing: event notification failure

by palin

Hi Heiko, "heiko.braun(a)jboss.com" wrote : a) notification failures: sure, it sound reasonable to track them through the SubscriptionManager. Resending (means queuing) would require additonal constraints (expiration policy, softening, etc). This already sounds like jms integration to me. I was thinking about that in the beginning, if further QoS capabilities can be delegated to an JMS instance. we've just created a patch to track notification failures through the SubscriptionManager mbean: http://jira.jboss.com/jira/browse/JBWS-1406 bye Alessio Soldano http://www.javalinux.it/blogs/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990126#3990126 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990126

17 years, 5 months

1
0
0 / 0

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

by palin

"palin" wrote : "heiko.braun(a)jboss.com" wrote : Please go on. I'd be more then happy to see more contributions like this. | Perfect :-) we'll go on then; please let us know something about svn priviledges you spoke us about by email (and eventually how you manage branches) OK, I've just read your last email about this, we'll create a patch for this issue and send it to you. Thank you. Alessio Soldano http://www.javalinux.it/blogs/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989798#3989798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989798

17 years, 5 months

1
0
0 / 0

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

by palin

"heiko.braun(a)jboss.com" wrote : I just talked to jason. He made up my mind: the addressing issue and state replication are actually two different problems. | | In order to get you started i suggest you forget about the addressing problems for now and take a look at jboss cache for replicating the subscriptions across cluster nodes. We'd need an abstraction though, that can be addressed from the subscription manager and comes in two flavors: cluster aware (jbosscache) and in-memory (the default). | IMO this should be some general purpose StateManager that offers a hashmap like API to get and set data. OK, I think this is equivalent to our first proposed solution, so I think we'll go this way anonymous wrote : | This would only leave us with the question how to deal with node shutdowns and subscription end messages... | Well, ideally we would expect shutdown messages to be sent by a cluster node going down when no other node of the cluster is up, otherwise the system shouldn't generate any shutdown message. I imagine the proposed StateManager could help us in this. anonymous wrote : Please go on. I'd be more then happy to see more contributions like this. Perfect :-) we'll go on then; please let us know something about svn priviledges you spoke us about by email (and eventually how you manage branches) anonymous wrote : yes, working on trunk would be better. but since you are going to put in production it's your decision. If we stick with branch 1.x then it needs to merged with trunk along the way... Actually I think this feature would be very useful for us in production as soon as it's ready... but I fear the merge could be not so trivial... anyway I'll speak with Stefano (maeste) tomorrow and we'll let you know for sure. Alessio Soldano http://www.javalinux.it/blogs/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989767#3989767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989767

17 years, 5 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

anonymous wrote : | is it better it will go in jbossws 2.0? | yes, working on trunk would be better. but since you are going to put in production it's your decision. If we stick with branch 1.x then it needs to merged with trunk along the way... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989759#3989759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989759

17 years, 5 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

| Can I go on, or do you prefer a committer working on that? | Please go on. I'd be more then happy to see more contributions like this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989755#3989755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989755

17 years, 5 months

1
0
0 / 0

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

by heiko.braun＠jboss.com

I just talked to jason. He made up my mind: the addressing issue and state replication are actually two different problems. In order to get you started i suggest you forget about the addressing problems for now and take a look at jboss cache for replicating the subscriptions across cluster nodes. We'd need an abstraction though, that can be addressed from the subscription manager and comes in two flavors: cluster aware (jbosscache) and in-memory (the default). IMO this should be some general purpose StateManager that offers a hashmap like API to get and set data. This would only leave us with the question how to deal with node shutdowns and subscription end messages... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989753#3989753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989753

17 years, 5 months

1
0
0 / 0

[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, 5 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, 5 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev November 2006