[JBoss JIRA] Created: (JBAS-4815) UnifiedInvokerProxyHA - Client instance check and assignment should be atomic
by Galder Zamarreno (JIRA)
UnifiedInvokerProxyHA - Client instance check and assignment should be atomic
-----------------------------------------------------------------------------
Key: JBAS-4815
URL: http://jira.jboss.com/jira/browse/JBAS-4815
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Remoting
Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
I have realised that UnifiedInvokerProxy/UnifiedInvokerProxyHA maintain a instance reference to
the InvokerLocator/Client instances to a specific invocation is using. That is, when a new target is
chosen, the unified proxy updates its Client and corresponding InvokerLocator instances (if they've
changed), and uses the Cient instance variable to make the call. As far as I can see there's no
synchronisation in the usage/assignment of Client or InvokerLocator. Proxies are meant to be thread
safe which means that multiple client app threads could be using the same proxy without any problems.
I can see all this going wrong the moment someone uses client proxies this way in a clustered
environment with round robin load balance policy. We've got no guarantee that round robin will work
correctly in these situations.
Several solutions have been discussed in
--
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, 5 months
[JBoss JIRA] Created: (JBCACHE-890) Custom flags per node, incorporate and consolidate some domain-specific flags
by Elias Ross (JIRA)
Custom flags per node, incorporate and consolidate some domain-specific flags
-----------------------------------------------------------------------------
Key: JBCACHE-890
URL: http://jira.jboss.com/jira/browse/JBCACHE-890
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
I believe that with java.util.EnumSet and a list of enumerations, that some of the specific flags we track on a node could be consolidated. Immediately what comes to mind are the CacheLoader flags "childrenLoaded" and "dataLoaded"
Further, I believe that some additional functionality could be incorporated.
For instance:
1. For certain internal nodes, they could be marked as "internal" or "local" and not replicated. Or possibly hidden from access entirely.
2. Some nodes might be marked as "read-only" or "non-persisted" or "non-evictable"
3. Some nodes might have special sorted ordering.
--
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, 5 months
[JBoss JIRA] Created: (JBCACHE-1218) System property substitution in config file parsing
by Brian Stansberry (JIRA)
System property substitution in config file parsing
---------------------------------------------------
Key: JBCACHE-1218
URL: http://jira.jboss.com/jira/browse/JBCACHE-1218
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Since JBC parses its own config files it would be nice to support the ${some.system.property:somedefault} syntax. This should be trivial to do; just add callouts to org.jboss.util.StringPropertyReplacer.replaceProperties(String) in XmlHelper.getAttributeValue() and XmlHelper.getElementContent().
This could even be helpful in JBoss AS if XmlParsingConfigurationRegistry is used -- the normal AS parsing wouldn't be used in that case. But, it would be simple enough though for me to write a different ConfigurationRegistry that had its config injected from MC beans rather than parsing the XML itself.
Manik, I left this assigned to you to give you a shot at making any inputs. If you think its worthwhile, feel free to assign back to me.
--
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, 5 months