[Clustering Development] - Exposing Infinispan CacheManager's in the AS
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Exposing Infinispan CacheManager's in the AS"
To view the discussion, visit: http://community.jboss.org/message/533814#533814
--------------------------------------------------------------
Discussion thread related to https://jira.jboss.org/jira/browse/JBAS-7838 https://jira.jboss.org/jira/browse/JBAS-7838
I was talking to Bela today about adding scopes to JGroups messages (see https://jira.jboss.org/jira/browse/JGRP-822 https://jira.jboss.org/jira/browse/JGRP-822) and the solution to that is still a bit up in the air. He's got clear ideas and may have something done pretty shortly, but IMO it's risky for the AS to count on having a scoping solution in JGroups and consumed by Infinispan in time for AS 6.0 M4.
Without a good scoping solution, I think it's wise to have different services (i.e. web session management, SFSB management, Hibernate 2LC, HAPartition) use a separate JGroups channel. Otherwise messages from one service will block in the receiver's NAKACK/UNICAST behind other messages from the same sender for different services.
This means we would use a different CacheManager for the different services. JBAS-7838 says to just use one by default, but I'm pretty convinced we should have more than one. We need to support that in the long run anyway.
Options, comments are appreciated:
1) Everything shares a single CacheManager/Channel.
2) 4 separate channels: Web, SFSB, Hibernate, HAPartition. A la AS 5.
3) 3 separate channels: Web+SFSB, Hibernate, HAPartition. Here web sessions and SFSBs use the same channel, which can be useful in the future when Infinispan supports sending a single 2PC message pair at tx commit for a tx that crosses several caches. So, a web request modifies a session and modifies an SFSB, we could get a single 2PC.
Hmm, if the web session and SFSB mapped to different nodes with DIST, there would be 2 messages anyway, so the utility of #3 is less.
So, I'm leaning toward #2 but am quite open to persuasion.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/533814#533814]
Start a new discussion in Clustering Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 2 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Servlet Scanner plugin
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"Servlet Scanner plugin"
To view the discussion, visit: http://community.jboss.org/message/533807#533807
--------------------------------------------------------------
> This would translate to something like:- public Set<Class<?>> getClasses(VirtualFile classpathItem, Set<Class<? extends Annotation>> annotationsToLookFor) (from the Hibernate plugin, assuming it looks for annotation on fields, methods and type), or return a Map<Class<? extends Annotation>>, Class<?>>
Hibernate plugin only checks for class annotations.
I would not re-use it, better writting new behavior in separate plugin.
> - public Set<Class<?>> getClasses(List<VirtualFile> classpath, Set<Class<? extends Annotation>> annotationsToLookFor, Set<Class<?>> supertypesToLookFor) (note: in case there are multiple SCIs with HandlesType, this could be less efficient than using a map to pass the annotations/types to look for, and getting a map back; of course, it is simpler too)
Can you explain this one a bit more.
Or, why mix the parameters; annotation and supertypes?
We already have the annotations method, simply adding the supertypes, and the use Set intersection to get both?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/533807#533807]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 2 months