[JBoss JIRA] Created: (ISPN-256) Enable Infinispan SPIs to implement their own commands
by Galder Zamarreno (JIRA)
Enable Infinispan SPIs to implement their own commands
------------------------------------------------------
Key: ISPN-256
URL: https://jira.jboss.org/jira/browse/ISPN-256
Project: Infinispan
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 4.1.0.BETA1
Much nicer IMHO would be a nice SPI / plug point to allow applications to extend the set of commands. Let an app create an ExtensionCommand; if that comes in off the channel pass it off to the handler the application registered.
This could for example be used instead of the solution currently used in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818. In HHH-3818, the cache is used as a notification vehicle which is a bit of a hack and has some limitations for example when trying to implement a similar solution for evict(key) op.
Another use case for it would be HTTP session ownership, from Brian Stansberry:
(09:32:09 AM) brian_stansberry: ... it's just that only 1 server at a time s/b able to use a session
(09:32:25 AM) brian_stansberry: so on failover i send an extension command requesting ownership
(09:33:19 AM) brian_stansberry: there's actually a servlet spec requirement that only one server at a time access a session
(09:33:23 AM) brian_stansberry: ejb spec too
(09:33:37 AM) brian_stansberry: we don't properly handle that
...
(09:34:18 AM) brian_stansberry: basically it's a lock
...
(09:34:35 AM) brian_stansberry: that's all it is, a distributed lock
(09:35:03 AM) brian_stansberry: but once you have the distributed lock it's yours until you give it up
(09:35:29 AM) brian_stansberry: so once 1 request acquires it, subsequent requests to same server can just use a local lock
...
(09:41:59 AM) brian_stansberry: the key thing is there should only be a cluster-wide operation once per session
(09:42:11 AM) brian_stansberry: unless there is failover
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-272) recover from transaction failures
by Mircea Markus (JIRA)
recover from transaction failures
---------------------------------
Key: ISPN-272
URL: https://jira.jboss.org/jira/browse/ISPN-272
Project: Infinispan
Issue Type: Feature Request
Components: Transactions
Affects Versions: 5.0.0.GA
Reporter: Mircea Markus
Assignee: Manik Surtani
We currently don't support any sort of recovery from transaction failures.
E.g.
tm.start();
database.delete(account);
ispnCache.put(account);
tm.commit():
At tm commit:
-prepare is successful on both enlisted resources.
- database.commit - fails
What shall we do with the locks/state from ispnCache.
Possible solutions:
- configure to automatically commit/rollback after a timeout
- keep locks on resources and allow manual intervention through JMX
- others?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-748) provide an API to expose core operations omitting return values as safe alternative to Flags
by Sanne Grinovero (JIRA)
provide an API to expose core operations omitting return values as safe alternative to Flags
--------------------------------------------------------------------------------------------
Key: ISPN-748
URL: https://jira.jboss.org/browse/ISPN-748
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Reporter: Sanne Grinovero
Assignee: Manik Surtani
Priority: Minor
Fix For: 5.0.0.BETA1, 5.0.0.Final
On mailing list we discussed the possibility to provide the same methods as defined by Map but omitting return values.
This would be useful for those cases in which return values are not needed, so that Infinispan can enable all possible optimizations to disregard retrieveing an appropriate return value.
Several alternatives where proposed, and there's also an interesting proposal to do the same relating to async methods, and the combination of async+noReturn
A suggestion:
cache.noReturnValue().remote(K); //returns void and enables both flags SKIP_CACHE_LOAD and SKIP_REMOTE_LOOKUP.
The advantage is that people refactoring code don't have to remember to adjust flags according to using the return value or not, or would at least get a compiler error in case of abuse of method; also Infinispan might introduce more optimizations in future and apply them without code changes for new flags arising.
See all discussion started by: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006484.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-833) Revisit cache name predefinition limitation for cache servers
by Galder Zamarreño (JIRA)
Revisit cache name predefinition limitation for cache servers
-------------------------------------------------------------
Key: ISPN-833
URL: https://issues.jboss.org/browse/ISPN-833
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.0.0.BETA1, 5.0.0.Final
There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches:
1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days.
2. Infinispan has issues dealing with asymmetric clusters (ISPN-658).
Once these two issues have been resolved, revisit the limitation.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-847) Eviction with strategy but no maxEntries does not make sense
by Galder Zamarreño (JIRA)
Eviction with strategy but no maxEntries does not make sense
------------------------------------------------------------
Key: ISPN-847
URL: https://issues.jboss.org/browse/ISPN-847
Project: Infinispan
Issue Type: Bug
Components: Configuration, Eviction
Affects Versions: 5.0.0.ALPHA1, 4.2.0.Final
Reporter: Galder Zamarreño
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 5.0.0.BETA1, 5.0.0.Final
A configuration like this can be confusing cos no maxEntries is set, and without it there's no trigger to start evicting stuff:
<default>
<eviction strategy="FIFO" wakeUpInterval="6000" /><!-- 6 seconds -->
</default>
So, we should come up with some WARN/ERROR message indicating that maxEntries is missing unless NONE strategy is used.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months