[JBoss JIRA] (ISPN-4104) RHQ server plugin: generic store cache child creation fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4104?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-4104:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> RHQ server plugin: generic store cache child creation fails
> -----------------------------------------------------------
>
> Key: ISPN-4104
> URL: https://issues.jboss.org/browse/ISPN-4104
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Reporter: Tomas Sykora
> Assignee: William Burns
>
> This issue is similar to: https://issues.jboss.org/browse/ISPN-4103
> I can see this error during server restart:
> 10:38:01,682 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "clustered"),
> ("distributed-cache" => "namedCache")
> ]) - failure description: "JBAS010292: org.infinispan.persistence.file.SingleFileStore is not a valid cache store"
> After issuing of operation this configuration fragment is added into standalone.xml configuration file: <store name="genericStore" class="org.infinispan.persistence.file.SingleFileStore" preload="true" passivation="false" purge="false"/>
> Child creation using not generic, but pure File Cache Store option works OK. Store is configured and using this class: org.infinispan.persistence.file.SingleFileStore, however, when trying to do the same using generic store creation, it fails.
> See error in linked JIRA (for loader) as I suspect there is the same cause for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-263) Handle cluster partitions
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-263?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-263:
-------------------------------
Labels: MERGE roadmap split_brain (was: MERGE split_brain)
> Handle cluster partitions
> -------------------------
>
> Key: ISPN-263
> URL: https://issues.jboss.org/browse/ISPN-263
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Labels: MERGE, roadmap, split_brain
>
> JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well.
> Analogous to JBCACHE-471
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3355:
--------------------------------
Labels: roadmap (was: )
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: William Burns
> Labels: roadmap
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> As opposed to the current listener approach in Infinispan ( a listener instance is invoked on the data owners ), this JIRA is about adding support for a cluster listener: the same listener instance that is notified disregarding of data ownership ( RPC calls involved).
> Due to the fact that the listener notification might involve an RPC, it is nice to be able to specify filters on these listeners.
> The clustered listener support opens the way for some interesting architectures:
> * persistent/continuous queries: the query is transformed in a filter. On each notification, the listener (stateful) updates the query state
> * simplistic CEP can be built on top of the persistent query described above
> * remote/hotrod notifications might be based on clustered listeners as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-2284) Execute Mapper and Reducer tasks in parallel where possible
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2284?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2284:
--------------------------------
Labels: roadmap (was: )
> Execute Mapper and Reducer tasks in parallel where possible
> -----------------------------------------------------------
>
> Key: ISPN-2284
> URL: https://issues.jboss.org/browse/ISPN-2284
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.0.Alpha3
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Labels: roadmap
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: Infinispan-MapReduce Job Times.png
>
>
> In our current implementation of Map/Reduce, Mapper and Reducer tasks executed on remote JVMs load and process key/values serially on a single thread. Where and if possible we should use executors to process keys/values in parallel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years