[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
[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
[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