[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2342 started by Pedro Ruivo.
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 6.0.1.Final
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
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, 2 months
[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo reassigned ISPN-2342:
---------------------------------
Assignee: Pedro Ruivo (was: Erik Salter)
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
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, 2 months
[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2342:
------------------------------
Affects Version/s: 6.0.1.Final
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 6.0.1.Final
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
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, 2 months
[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2342:
------------------------------
Fix Version/s: 7.0.0.Alpha1
7.0.0.Final
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 6.0.1.Final
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
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, 2 months
[JBoss JIRA] (ISPN-3903) Transaction Code Optimizations
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3903?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3903:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2340
> Transaction Code Optimizations
> ------------------------------
>
> Key: ISPN-3903
> URL: https://issues.jboss.org/browse/ISPN-3903
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 6.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1
>
>
> Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress):
> * the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap()
> * TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction).
> * Refactor LocalTxInvocationContext and RemoteTxInvocationContext
> Results (for 5 min profiling):
> * HashMap allocation reduced from 20.80GB to 3.76GB
> * LocalTxInvocationContext allocation reduced from 13.80GB to 7.44GB
--
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, 2 months
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3355:
--------------------------------
Fix Version/s: 7.0.0.Final
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: William Burns
> Fix For: 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, 2 months
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3355 started by William Burns.
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: William Burns
>
> 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, 2 months
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3355:
-------------------------------------
Desmond,
# Currently there is no plan for this in embedded mode. There were talks about adding this in a future iteration for embedded. Hotrod with remote listeners is planned to register a new listener on a new node. That is covered in ISPN-374
# The user can provide a Filter that can be used for given keys. The final plan is to have a Filter that can use the new Query DSL to filter these in ways like you mentioned. However core itself will not support the query filtering. This will require an additional module that is actively being worked on (don't know the JIRA)
# There is no thought of allowing this at this point. This doesn't preclude the ability for the user to trigger a write update in response to the event occurring though. However you should not raise such an event in the listener as this would cause a deadlock for synchronous events as it is fired when the lock is still acquired.
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: William Burns
>
> 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, 2 months
[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3904?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3904:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2339
> Migrate JDBC cache store tests
> ------------------------------
>
> Key: ISPN-3904
> URL: https://issues.jboss.org/browse/ISPN-3904
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: task
>
> Migrating finctional tests for JDBC cache store
> Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
--
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, 2 months
[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3904?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3904:
------------------------------------
Description:
Migrating finctional tests for JDBC cache store
Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
was:
Migrating finctional tests for JDBC cache store
Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation
, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
> Migrate JDBC cache store tests
> ------------------------------
>
> Key: ISPN-3904
> URL: https://issues.jboss.org/browse/ISPN-3904
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: task
>
> Migrating finctional tests for JDBC cache store
> Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
--
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, 2 months