August 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

My ignorance of portal internals is becoming apparent. I'd thought portlet sessions were managed as data stored inside the overall javax.servlet.http.HttpSession. So, either: 1) You guys are overriding the standard HttpSession replication config and substituting your own cache for the one defined in deploy/jboss-web-cluster.sar 2) I'm clueless and portlet sessions are using a completely different replication mechanism. I suspect #2. :-) What to do depends on which it is. If #1, the answer depends on why you replaced the standard HttpSession replication cache. If there's not a good reason, go back to using the standard cache, but enable buddy replication. If #2, you guys have developed your own independent clustering technology, and I can only make general comments: a) Generally "sessions" of whatever type should be "owned" by a particular node in the cluster. The only reason to replicate them is to provide HA in the unexpected case of failover. Generally REPL_ASYNC is used for this, as it scales much better. The downside is the potential loss of state if failover happens before the latest replication message arrives. In most cases that risk is acceptable in order to get better performance. INVALIDATION can't be used for a session cache. The only place the session exists is in the cache. If you invalidate it instead of replicating, you have no HA. Entities are shared by all nodes, and an entity cache should use SYNC communication for the reasons already discussed. Bottom line, using the same cache for both entities and sessions is not a good approach. b) Generally, turning on buddy replication for a "session" cache should only be done if the cache integration layer has been written with BR in mind. It's not a simple matter of changing a config flag and voila, it works. The standard HttpSession cache integration layer has been written with BR in mind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168791#4168791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168791

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by bstansberry＠jboss.com

The registration/unregistration of interceptors should be tied to the existence of the interceptors. If Cache.stop() removes the interceptors, then the unregistration should move to CacheJmxWrapper.stop(). And of course they shouldn't be registered before they exist. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168788#4168788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168788

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by adrian＠jboss.org

JBDEPLOY-66 should be 100% backwards compatible. I've raised JBDEPLOY-70 to remove these backwards compatiblity methods once JBossAS/OSGi ahve been update to the new api. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168779#4168779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168779

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by adrian＠jboss.org

While doing this code, I noticed there was a bug in FileStructure. It goes to some effort to set a flag called "isFile" but the bug was it added the file as a subdeployment regardless of whether that flag was set. This probably doesn't cause any problems since nothing will recognise the file for metadata purposes and it has no classpath, but it is obviously stupid. The patch is pretty simple: | | // Create a context info for this file | + if (isFile) | context = createContext(structureContext); | // There are no subdeployments for files | if (trace) | log.trace(file + " isFile: " + isFile); | return isFile; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168777#4168777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168777

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by manik.surtani＠jboss.com

There are some incompatibilities such as Fqn ctors. The reason why I asked about the JMX wrapper is because there is some unregistering code in destroy which isn't there in stop. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168776#4168776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168776

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - StructureContext and candidate annotations

by adrian＠jboss.org

https://jira.jboss.org/jira/browse/JBDEPLOY-66 I've done the basic StructureContext stuff. That's leave Ales to do the JBDEPLOY-67. The basic idea of JBDEPLOY-67 is introduce a new mode to the candidate deployment visitor. Where we not only check that we recognise the context, but also check whether the context has one a given set of annotations. I'd suggest: 1) Add a property to StructureContext, something like | boolean candidateAnnotationScanning; | 2) In MockEARStructureDeployer add code to visit children in this mode | structureContext.setCandidateAnnotationScanning(true); | addAllChildren(structureContext); | 3) Add a new property to StructureDeployer | boolean supportsCandidateAnnotations; | The default should be false and avoids invoking structural deployers that don't understand what this means. 4) In StructureDeployerWrapper, ignore StructureDeployers where this property is false when the candidateAnnotationScanning is enabled. 5) Add support to AbstractStructureDeployer to scan for annotations i.e. add a | Set<Class<? extends Annotation>> candidateAnnotations; | with a helper method. Currently the MockEARStructureDeployer does this wrong because it is using the vfs resource visitor, which doesn't exist at this point - no classloader. 6) Modify JARStructureDeployer to invoke the additional annotation scan check when candidateAnnotationScanning is enabled and if it fails, do a structureContext.removeChild(context); that it just created. This check should happen before it itself looks for subdeployments. It's important that it only includes the root in the scanning since we don't want to add a jar to an ear if it is a class in one of the manifest jars that has an annotation. This seems to me the easiest way to resolve the issue with minimal disruption to the logic in other structure deployers. i.e. You have to explicitly write and configure this behaviour on your structure deployer. If we decide we should do the same thing for wars in the future it should be easy to reuse the same code. As long as the helper code supports multiple roots in the virtual files to scan, i.e. WEB-INF/classes and WEB-INF/lib/*.jars It also externalises the annotations that we look for, so we can add things like JBoss's EJB3 @Service or anything new that comes along. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168775#4168775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168775

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by bstansberry＠jboss.com

Re: getting rid of create/destroy altogether, how many other significant incompatible changes to the API have been made? If we got rid of the Fqn constructors as was discussed at the beginning of this thread, ignore the rest of this post. :-) If the API is basically compatible w/ 2.x, that's an argument for leaving create/destroy around even if we internally move their functionality to start/stop. That is, don't make people rewrite their apps/prevent upgrades for a minor API cleanliness benefit. No longer having Fqn constructors means nearly everyone has to rewrite their apps, in which case might as well clean up whatever you can. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168772#4168772 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168772

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by kukeltje

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

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by bstansberry＠jboss.com

Re: CacheJmxWrapper, it should be OK. It doesn't do anything in create() that it can't do in start(). So, we can either: 1) Remove create() altogether from CacheJmxWrapper . 2) or leave it there but remove the call to Cache.create(). #1 seems illogical but has minor advantages. One of the things CacheJmxWrapper,create() does is instantiate the cache if one wasn't injected. Leaving that in a "create" step allows sophisticated users to get a ref to the cache via CacheJmxWrapper.getCache(), register listeners, etc, before start() is called. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168767#4168767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168767

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-166 - TreeSet/Map, LinkedHashMap

by manik.surtani＠jboss.com

>From another thread that I started by mistake. "manik.surtani(a)jboss.com" wrote : | This is referring to: | | https://jira.jboss.org/jira/browse/JBCACHE-841 | | And rather than exposing the backing Map impl to users, I'd prefer to just provide a few settings on a node such that: | | | Node.isDataOrdered(); // tests if the data map is ordered | | Node.isChildrenOrdered(); // tests if the child map is ordered | | Node.setDataOrdered(boolean b); // locks the map, and then copies out the existing data map into a new ordered map structure | | Node.setChildrenOrdered(boolean b); // similar to above | | | Is there anything else we'd need? Using iterators on the sets and maps returned when accessing data/data-keys/children/children-names will be ordered if the node is set to be ordered. I guess perhaps providing comparators if the data has no natural ordering would be useful? This comparator would have to be serializable though if it is to be replicated/persisted. | | | | Node.setDataComparator(Comparator<K> c); | | | I'm guessing we'd need a SortedMap similar to FastCopyHashMap that is optimised for copying/cloning? | | Finally, these settings would have to be replicated/persisted. I'm guessing there should be no special options on cache loaders, but when the data is loaded into the node it would be ordered by the map implementation. | | Also, I see this as a per-node option. Any thoughts on whether this would be useful as a cache-wide cfg option? There may be cases where a thread is reading a node in a tx, and another thread sets it's sorted flag to true. I'm guessing flag changes like these are considered a write operation since the map implementation changes and a copy of contents will take place. Or - to make life easier - do we want this to be cache-wide so that all nodes are either sorted or not, and there is no issue with changing them? | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168758#4168758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168758

17 years, 4 months

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 August 2008