September 2006 - jboss-dev-forums

[Design of JBossCache] - state transfer failure handling

by vblagojevic＠jboss.com

Hey, Complete state transfer, as you might be aware, consists of transferring transient (in-memory) state, associated state (pojo reference map) and persistent state (state fetched from cacheloader). All three states are part of the stream passed between state recipient and state receiver. Current implementation does not follow all-or-nothing approach when it comes to potential failures. Let me elaborate. At state recipient we get a stream that contains all three states demarcated by special node markers and possibly some error markers if state generation at state provider threw exception(s). If we encounter error markers during stream reading we clear appropriate part of the cache at integration Fqn. Thus during transient state reading if we encounter error markers we clear transient state at state recipient cache node. Similarly if we encounter error markers during persistent state reading we clear underlying cacheloader recipient. As things stand right now we try to read persistent state from stream even though transient or associated transfer part of the stream contained error marker(s) and were thus not integrated in recipients cache. Should we keep the current approach and, if not, what are you arguments against the current approach? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971361#3971361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971361

19 years, 6 months

1
0
0 / 0

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

by vblagojevic＠jboss.com

Brian, There is no way that at the time block is propagate up from FLUSH to Channel that we know which node is a state provider. The only parameter with BLOCK event that we could possibly send up the stack is the identity of the node that invoked FLUSH. In the case of state transfer that node is state requester. So as you suggest we'll have to do some additional work once getState reaches state provider. The call for unblock, as Bela explained today privately, is: Pull model (Channel.receive()): Channel.blockOk() Push model (Receiver.block()): Returning from block() is an ack, so Channel.blockOk() does *not* need to be called ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971353#3971353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971353

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Registry Design

by anil.saldhana＠jboss.com

Assuming you want to prototype and plan to use JAXR against jUDDI, here are some relevant details. | * Pick up Scout/juddi versions from jboss-4.0.4.GA | * Create a version of the juddi transport interface. Scout will use this transport to communicate to juddi. So you can make a local call here (not use soap or any transport). | Eg: | http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/jbosstest/build.xml?onl... | | * There is a bloated JUDDI Servlet that picks up the incoming soap message, parses the uddi op and then calls its internal infrastructure. So you will need to peek in and assume that you have the uddi op (as you are making a local call in the transport) and pick up the infrastructure call and plug it into the transport that you used in aforementioned step. | | http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/contrib/varia/src/main/... | | So basically you have removed the extra step of marshalling in the transport and unmarshalling in a servlet. You have combined the scout and juddi via a local call in the transport. | | Underneath, Scout uses juddi proxy to communicate and this transport interface is part of it. | This info is for Kurt. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971351#3971351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971351

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Action Processing Pipelines on Listeners/Pollers...

by tfennelly

Another enhancement to this could be the ability to configure "default" pre-processing ActionProcessors for specific listener classes - these actions get inserted at the start of the configured pipeline. This could be used e.g. for message normalisation (a hot topic at the moment ;-) ). So for e.g. the JMSListener you could have a default action processor that "normalises" the based on a combo of JMS and your chosen normalisation strategy. So the "Actions" config might look something like: <Actions> |  |  | | <DefaultActions listener="listenerA" actions="action-list..." /> | <DefaultActions listener="listenerB" actions="action-list..." /> | </Actions> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971312#3971312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971312

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Runtime changes of cache config elements

by bstansberry＠jboss.com

You might want to ping Scott/Adrian to see how this ties in with what they are doing. They have a concept of a ManagedObject that's meant to describe this kind of thing. I'm sure tools like JBoss ON are going to want a consistent API for discovering what features are runtime changeable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971305#3971305 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971305

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Runtime changes of cache config elements

by manik.surtani＠jboss.com

I've created a new annotation to go with org.jboss.cache.config.Configuration - @Dynamic. This annotation is applied to fields in the Configuration class and if a setter is called on a Configuration object, if the cache is running and the field the setter modifies does not have the @Dynamic annotation a ConfigurationException is thrown. Easy way to control configuration changes on a running cache - the only question is, which elements should be treated as dynamic? :) Here is an initial list of the fields: | private String clusterName = "TreeCache-Group"; | private String clusterConfig = null; | private boolean useReplQueue = false; | @Dynamic | private int replQueueMaxElements = 1000; | @Dynamic | private long replQueueInterval = 5000; | private boolean useInterceptorMbeans = true; | private boolean fetchInMemoryState = true; | private short replicationVersion = DEFAULT_REPLICATION_VERSION; | private String replVersionString = Version.getVersionString(DEFAULT_REPLICATION_VERSION); | @Dynamic | private long lockAcquisitionTimeout = 10000; | @Dynamic | private long syncReplTimeout = 15000; | private String evictionPolicyClass = null; | private CacheMode cacheMode = CacheMode.LOCAL; | private boolean inactiveOnStartup = false; | private String serviceName; | private long initialStateRetrievalTimeout = 10000; | private IsolationLevel isolationLevel = IsolationLevel.REPEATABLE_READ; | @Dynamic | private Element evictionPolicyConfig = null; | private boolean useRegionBasedMarshalling = false; | private String transactionManagerLookupClass = null; | private Element cacheLoaderConfiguration = null; | @Dynamic | private boolean syncCommitPhase = false; | @Dynamic | private boolean syncRollbackPhase = false; | private Element buddyReplicationConfig; | private boolean nodeLockingOptimistic = false; | private NodeLockingScheme nodeLockingScheme = NodeLockingScheme.PESSIMISTIC; | private String muxServiceName = null; | private String muxStackName = "fc-fast-minimalthreads"; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971301#3971301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971301

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

With both approaches, though, there is no way to remove or replace any of the default interceptors - just a way to add more. Removing/replacing would have to be done via the CacheSPI interface. Can anyone think of a way to allow removing/replacing via XML as well, without bloating out to a full-blown expression language? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971253#3971253 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971253

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

Or is something like this more preferable/simpler to configure? | <attribute name="InterceptorChainCustomisation"> | <config> |  | <interceptor class="a.b.c.d" params="" /> | |  | <generated-chain /> | |  | <interceptor class="a.b.c.f" params="" /> | </config> | </attribute> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971252#3971252 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971252

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Designing Habanero - Configuration changes

by manik.surtani＠jboss.com

Reviving this thread. Do we see any use in being able to add custom interceptors via XML? E.g., an XML element like: | <attribute name="CustomInterceptors"> | <config> | <interceptor> |  | <class>com.microsoft.SecurityLoopholeInterceptor</class> | |  | <attribute name="Enabled">true</attribute> | <attribute name="CustomSetting1">Blah</attribute> | |  | <chainPosition>3</chainPosition> | </interceptor> | </config> | </attribute> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971251#3971251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971251

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Action Processing Pipelines on Listeners/Pollers...

by mark.little＠jboss.com

We'll need to figure out how this can fit in with the dispatcher work. Maybe you've already got that worked out ;-)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971240#3971240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971240

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