September 2006 - jboss-dev-forums

[Design of JBossCache] - Re: state transfer failure handling

by bela＠jboss.com

Do we lock the root node for the *persistent* state transfer, like in the case of the in-memory state ? Would it maybe be better to lock on the CacheLoader in question rather than on the root node ? Possible inconsistencies ? Usually, the persistent state is *much bigger* than the in-memory state, so locking the entire tree for the persistent state transfer might take a long time... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971474#3971474 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971474

19 years, 6 months

1
0
0 / 0

[TODO - DEVELOPMENT] - Re: Advanced: client side interceptors

by mkislina

Hello, * Can I use Interceptor to provide an access for EJB clients to HA-JNDI from different networks? (JBoss is running on a multihomed host) Any hint is appriciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971470#3971470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971470

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: Help, can not send email to hotmail.com?

by gohip＠ichibancomputers.com

is it going in the hotmail junk email folder? hotmails feisty about what it deems as junk mail good luck oh, look in your server logs, and see if it is at least connecting to the server (hotmail), you might see an error code? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971467#3971467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971467

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Integration of new deployers into MC-VDF-WORK

by scott.stark＠jboss.org

An spi to convert a raw deployment archive into a DeploymentContext is missing from the updated MainDeployer. I have to go to the AbstractDeploymentContext implementation in plugins to associate a raw deployment archive to a DeploymentContext via a VirtualFile. For the jsr88 aspect of the profile service I at least need a way to obtain the StructureDeployer to populate the AbstractDeploymentContext given the deployment VirtualFile to add to the profile. A mapping of the ManagedObject(s) for the DeploymentContext is also missing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971464#3971464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971464

19 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Problem with deploy-hasingleton and applications

by kurt_olsen

Thanks Dimitris View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971463#3971463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971463

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Locking tree before setting initial state

by bstansberry＠jboss.com

OK, so there's no "unblock" call. That seems a minor flaw in FLUSH, as it doesn't give the application an opportunity to make any kind of state transition upon completion of the whole FLUSH cycle. The only knowledge the app has that the FLUSH is finished is that suddenly messages start flowing up/down the channel again. No matter; that's an issue for another day and I don't think an issue for the current problem. Refining what I proposed last time. I'll use the pull model, although TreeCache implements MembershipListener so I think it would get the block() call. 1) Receive BlockEvent on all nodes a) set a flag or something that will block any ACTIVE transactions from proceeding (i.e. entering prepare() phase of 2PC) b) wait for complete / rollback any transactions that are beyond ACTIVE c) call Channel.blockOk(). d) reverse the flag set in a) so transactions can now enter prepare(). But, the channel will prevent the prepare() call going out on the cluster 2) In getState() on node that's providing state, execute something pretty much like what I already wrote to deal with ACTIVE transactions on that node or any leftover locks held by sick nodes. 3) No need for #3. Flag already reversed in 1d; when FLUSH is done, the blocked prepare() calls will start to flow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971462#3971462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971462

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Moving core o.j.invocation classes to common

by scott.stark＠jboss.org

org.jboss.aop.util.{MarshalledValue,MarshalledValueInputStream,MarshalledValueOutputStream} are just copies of the server classes that only have dependencies on j2se classes. They could easily be moved to the common project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971461#3971461 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971461

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Moving core o.j.invocation classes to common

by bstansberry＠jboss.com

OK, good. Putting a bunch more classes into common-core didn't have a good feel to it, kind of the first step on the road to making common-core a dumping ground. If there's another natural home for this style of class, that's better. Except...I do think MarshalledValueIn(Out)putStream belong in common. Server or aop version, whichever. Unless I missed something those are just utility classes. Having to pull in an aop-mc-int binary just to use those 2 kinda sucks. Unless in the end anyone who uses them (i.e. JBC) is going to end up depending on the microcontainer binaries anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971460#3971460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971460

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers, ContextData and MangedObjects

by scott.stark＠jboss.org

As described, I'm not seeing much distinction between a scope and a subcontext. Espcially for the case of the enc handling, this would seem to be more of a metadata scope with the key and scope set at runtime by an enc aspect. For a invocation, the enc aspect queries for the enc context created during deployment starting at the instance level, and finds it at different levels depending on the deployment type. Fleshing out simple resusable aspects and associated deployers for things like an enc, security and logging for kernel beans is what we should look at to flesh this out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971458#3971458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971458

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: state transfer failure handling

by bstansberry＠jboss.com

My gut instinct is for an atomic approach as well. The only use case where continuing after partial failure is conceptually valid is when the persistent state contains a complete representation of the state; transient state is just there to provide a hot cache. 1) There has to be a persistent state transfer or a shared cache loader. 2) No passivation. Then, if you're going to fall back and rely on persistent state, you have to be sure you can remove any in-memory state that may have been integrated before the failure. If associated state fails, you have to clear transient as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971456#3971456 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971456

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 September 2006