[JBoss JIRA] Created: (JBAS-4455) LoadBalancePolicy that tries to pin all requests associated with a tx to one server
by Brian Stansberry (JIRA)
LoadBalancePolicy that tries to pin all requests associated with a tx to one server
-----------------------------------------------------------------------------------
Key: JBAS-4455
URL: http://jira.jboss.com/jira/browse/JBAS-4455
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Galder Zamarreno
Priority: Minor
The HA proxies don't allow failover once a tx has reached a server. This can lead to this kind of situation:
EJB A deployed on nodes 1 and 2.
EJB B deployed on nodes 1 and 2.
1) Start tx, invoke on A.1.
2) Lookup B.
3) Invoke on B. LB policy picks B.2
4) Node 2 is dead for some reason so call fails.
5) Can't fail over because tx context won't allow a failover after a call has reached a server.
But, B.1 is fine and is running on the only node the tx has invoked on. :(
Approach to improving this. This is based on JRMPInovkerProxyHA methods, but the idea is generic:
In invocationHasReachedAServer, instead of storing null as the value, you store the target (key is the tx).
In invoke, if there's a tx, you add that target (if there is one) to the invocation as transient metadata
The LB policy gets passed the invocation as an arg when it chooses a target (this is already in the API)
LB policy checks for the metadata. If there, and that target is in its target list, return that target
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 4 months
[JBoss JIRA] Created: (JBMETA-2) ClassCastException: org.jboss.metadata.ejb.spec.EntityBeanMetaData
by Scott M Stark (JIRA)
ClassCastException: org.jboss.metadata.ejb.spec.EntityBeanMetaData
------------------------------------------------------------------
Key: JBMETA-2
URL: http://jira.jboss.com/jira/browse/JBMETA-2
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: org.jboss.test.metadata.ejb.EjbJar21UnitTestCase.testMultipleMerge()
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: 1.0.0.Beta5
A merge of an ejb2.1 descriptor with a 4.0 jboss descriptor with 2 session and 1 entity beans is failing with:
java.lang.ClassCastException: org.jboss.metadata.ejb.spec.EntityBeanMetaData
at org.jboss.metadata.ejb.jboss.JBossSessionBeanMetaData.merge(JBossSessionBeanMetaData.java:820)
at org.jboss.metadata.ejb.jboss.JBossEnterpriseBeansMetaData.merge(JBossEnterpriseBeansMetaData.java:153)
at org.jboss.metadata.ejb.jboss.JBossMetaData.merge(JBossMetaData.java:722)
at org.jboss.test.metadata.ejb.EjbJar21UnitTestCase.testMultipleMerge(EjbJar21UnitTestCase.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 4 months
[JBoss JIRA] Created: (JBCACHE-1215) NullEvictionPolicy
by Brian Stansberry (JIRA)
NullEvictionPolicy
------------------
Key: JBCACHE-1215
URL: http://jira.jboss.com/jira/browse/JBCACHE-1215
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
An eviction policy that allows returns 'true' to EvictionPolicy.canIgnoreEvent(). Other methods are no-ops or equivalent defaults.
Use case is situations where there are multiple eviction regions in a cache, some of which should never evict anything. You could use an LRUPolicy with maxAge=0, maxNodes=0 to accomplish a similar thing, but then you incur wasted overhead of generating, queuing up and processing node events. NullEvictionPolicy just bypasses everything.
Some usages:
Hibernate timestamp caching. The timestamp region should never be evicted.
HttpSession caching with FIELD. I'll probably need to use JBC eviction for the JBossInternal_ area to passivate pojos. But passivating the sessions themselves should not be managed by JBC. So I could use NullEvictionPolicy for the session storage area.
Could also be inserted as a global default if JBC detects that the _default_ region wasn't configured while a subregion was.
I coded this up one night a while ago and forgot about it. Could be added to 2.1.0.GA if not too late; otherwise later.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 4 months