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

[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

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: Generalizing the JACC service

by danlee

Is there any plan to implement doAs for JAAS in the near future? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989797#3989797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989797

18 years, 1 month

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-880 discussion ...

by genman

"manik.surtani(a)jboss.com" wrote : And there actually has been a thread on the user forum about this too, although I still think usage only makes sense for pretty specific cases. | Web caching, session caching. JMS messages have expiration times. Almost every "business" object has some sort of lifespan or lifecycle. Actually, I need it for my own specific application, and I don't see any better way. What's currently done is there's a timer that wakes up and scans a list of cached values and removes any ones past its expiration time. Although it is fairly easy to implement as a plug-in, there's a lot of value of having it integrated and tested with the JBossCache product. anonymous wrote : | About your implementation - how does this work with existing eviction policies? Also, why the use of an 'expiration' element, vs. a more explicit attribute on Node - Node.setTTL() or something? | Adding an additional node element would require changing the interface for a fairly specific use case. It also increases the memory footprint of the Node. And since this expiration value might need to be stored in a cache loader or replicated, it would also require changes to those areas. setTTL() ultimately would likely have to call a series of interceptors, requiring more changes in TreeCache and everywhere ... I suppose it could simply translate into a "put()". anonymous wrote : | And what are the semantics of this - millis since last accessed, millis since created, or expiry at a specific time? Perhaps this is best in the form of a pluggable policy too? | Specific time is easier. TTL would be okay. But the question of replication comes up. Perhaps I'm confusing eviction with removal? The specific time would be most useful as an indication for node removal, not for passivation. Perhaps there should be a RemovalPolicy rather than EvictionPolicy? Anyway, I'd appreciate you looking at the test cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989791#3989791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989791

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

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

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: Problems with replicating entity queries via JBC

by bstansberry＠jboss.com

Absolutely. I didn't mean to imply that this meant it wasn't a serious problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989733#3989733 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989733

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Configure JBPM

by kukeltje

wrong forum btw, there is info on this in the documentation View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989732#3989732 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989732

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: DeploymentInfo and DeploymentContext information

by bill.burke＠jboss.com

DU-DC is a one-to-one relationship. Not one-to-many. The EJB Deployer only deals with DeploymentUnits. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989731#3989731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989731

18 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006