[JBoss JIRA] (ISPN-9885) write-skew Doc Feedback
by Don Naro (Jira)
Don Naro created ISPN-9885:
------------------------------
Summary: write-skew Doc Feedback
Key: ISPN-9885
URL: https://issues.jboss.org/browse/ISPN-9885
Project: Infinispan
Issue Type: Enhancement
Components: Documentation-Core
Affects Versions: 10.0.0.Beta2, 9.4.6.Final
Reporter: Don Naro
Assignee: Don Naro
https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht...
The attribute is deprecated, but it is not there (I've checked C/S mode only by now).
So the deprecation might be confusing to users
Anyway, the description should be
write skew is automatically enabled for for Repeatable Read + Optimistic locking
and this is the default for embedded mode !
Otherwise it will be disabled.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9884) SoftIndexFileStore.destroy leaks threads
by Dan Berindei (Jira)
Dan Berindei created ISPN-9884:
----------------------------------
Summary: SoftIndexFileStore.destroy leaks threads
Key: ISPN-9884
URL: https://issues.jboss.org/browse/ISPN-9884
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.5.Final, 10.0.0.Alpha2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta1
{{SoftIndexFileStore.destroy()}} doesn't call {{Index.stopOperations()}}, so the index threads keep on running.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback
by Don Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ]
Don Naro updated ISPN-9880:
---------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6613
> Docs: Hot Rod Transaction Support Feedback
> ------------------------------------------
>
> Key: ISPN-9880
> URL: https://issues.jboss.org/browse/ISPN-9880
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Affects Versions: 10.0.0.Beta2, 9.4.6.Final
> Reporter: Don Naro
> Assignee: Don Naro
> Priority: Major
>
> https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht...
> Feedback for on Hot Rod Transaction docs:
> Server Guide
> - 6.2.6 Transactions
> Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
> User Guide
> - 20.7.21.2.2 Transaction Modes
> "The transaction mode names are the same for server configuration and for client settings.
> To prevent from confusion it should be clarified here that this is the client setting
> and the server will not work correctly if the client use Tx but the server has no Tx setting.
> This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
> - 20.7.21
> "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
> But there is no highlighted node that the consistence is possibly affected by that.
> There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
> Additionally:
> "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
> If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
> So this will be 99% of the use cases (or more)"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback
by Don Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ]
Don Naro updated ISPN-9880:
---------------------------
Description:
https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht...
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
- 20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
was:
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
- 20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
> Docs: Hot Rod Transaction Support Feedback
> ------------------------------------------
>
> Key: ISPN-9880
> URL: https://issues.jboss.org/browse/ISPN-9880
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Affects Versions: 10.0.0.Beta2, 9.4.6.Final
> Reporter: Don Naro
> Assignee: Don Naro
> Priority: Major
>
> https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht...
> Feedback for on Hot Rod Transaction docs:
> Server Guide
> - 6.2.6 Transactions
> Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
> User Guide
> - 20.7.21.2.2 Transaction Modes
> "The transaction mode names are the same for server configuration and for client settings.
> To prevent from confusion it should be clarified here that this is the client setting
> and the server will not work correctly if the client use Tx but the server has no Tx setting.
> This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
> - 20.7.21
> "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
> But there is no highlighted node that the consistence is possibly affected by that.
> There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
> Additionally:
> "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
> If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
> So this will be 99% of the use cases (or more)"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9883) Control cluster configuration
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9883?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9883:
------------------------------------
Description:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with cloud.xml and in memory storage only
* type=Stateful: it will start a cluster backed by a stateful set
* type=Default: no configuration provided, will start a type=Stateless cluster
was:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Default: no config is provided, it will start the cluster using cloud.xml with memory persistence
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with in memory storage only
* type=Stateful: it will start a cluster backed by a stateful set
> Control cluster configuration
> ------------------------------
>
> Key: ISPN-9883
> URL: https://issues.jboss.org/browse/ISPN-9883
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
> * type=Custom: the user provides a configmap where the config is located
> * type=Stateless: it will start a cluster with cloud.xml and in memory storage only
> * type=Stateful: it will start a cluster backed by a stateful set
> * type=Default: no configuration provided, will start a type=Stateless cluster
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9883) Control cluster configuration
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-9883:
---------------------------------------
Summary: Control cluster configuration
Key: ISPN-9883
URL: https://issues.jboss.org/browse/ISPN-9883
Project: Infinispan
Issue Type: Feature Request
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Default: no config is provided, it will start the cluster using cloud.xml with memory persistence
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with in memory storage only
* type=Stateful: it will start a cluster backed by a stateful set
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9882) JdbcStringBasedStore leaks threads
by Dan Berindei (Jira)
Dan Berindei created ISPN-9882:
----------------------------------
Summary: JdbcStringBasedStore leaks threads
Key: ISPN-9882
URL: https://issues.jboss.org/browse/ISPN-9882
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.5.Final, 10.0.0.Alpha2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta1
When stopping, {{JdbcStringBasedStore}} only stops the connection factory if it implements {{ManagedConnectionFactory}}. {{PooledConnectionFactory}} doesn't implement it, so Agroal connection pools are not closed and leak threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9882) JdbcStringBasedStore leaks threads
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9882?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9882:
-------------------------------
Status: Open (was: New)
> JdbcStringBasedStore leaks threads
> ----------------------------------
>
> Key: ISPN-9882
> URL: https://issues.jboss.org/browse/ISPN-9882
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> When stopping, {{JdbcStringBasedStore}} only stops the connection factory if it implements {{ManagedConnectionFactory}}. {{PooledConnectionFactory}} doesn't implement it, so Agroal connection pools are not closed and leak threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback
by Don Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ]
Don Naro updated ISPN-9880:
---------------------------
Description:
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
- 20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
was:
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
> Docs: Hot Rod Transaction Support Feedback
> ------------------------------------------
>
> Key: ISPN-9880
> URL: https://issues.jboss.org/browse/ISPN-9880
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Affects Versions: 10.0.0.Beta2, 9.4.6.Final
> Reporter: Don Naro
> Assignee: Don Naro
> Priority: Major
>
> Feedback for on Hot Rod Transaction docs:
> Server Guide
> - 6.2.6 Transactions
> Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
> User Guide
> - 20.7.21.2.2 Transaction Modes
> "The transaction mode names are the same for server configuration and for client settings.
> To prevent from confusion it should be clarified here that this is the client setting
> and the server will not work correctly if the client use Tx but the server has no Tx setting.
> This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
> - 20.7.21
> "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
> But there is no highlighted node that the consistence is possibly affected by that.
> There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
> Additionally:
> "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
> If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
> So this will be 99% of the use cases (or more)"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback
by Don Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ]
Don Naro updated ISPN-9880:
---------------------------
Description:
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
was:
Feedback for on Hot Rod Transaction docs:
Server Guide
- 6.2.6 Transactions
Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
Additionally:
"to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
So this will be 99% of the use cases (or more)"
User Guide
- 20.7.21.2.2 Transaction Modes
"The transaction mode names are the same for server configuration and for client settings.
To prevent from confusion it should be clarified here that this is the client setting
and the server will not work correctly if the client use Tx but the server has no Tx setting.
This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
20.7.21
"The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
But there is no highlighted node that the consistence is possibly affected by that.
There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
> Docs: Hot Rod Transaction Support Feedback
> ------------------------------------------
>
> Key: ISPN-9880
> URL: https://issues.jboss.org/browse/ISPN-9880
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Affects Versions: 10.0.0.Beta2, 9.4.6.Final
> Reporter: Don Naro
> Assignee: Don Naro
> Priority: Major
>
> Feedback for on Hot Rod Transaction docs:
> Server Guide
> - 6.2.6 Transactions
> Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities.
> User Guide
> - 20.7.21.2.2 Transaction Modes
> "The transaction mode names are the same for server configuration and for client settings.
> To prevent from confusion it should be clarified here that this is the client setting
> and the server will not work correctly if the client use Tx but the server has no Tx setting.
> This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)"
> 20.7.21
> "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic.
> But there is no highlighted node that the consistence is possibly affected by that.
> There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible."
> Additionally:
> "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations.
> If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found.
> So this will be 99% of the use cases (or more)"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months