[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated ISPN-6574:
-----------------------------------
Status: Open (was: New)
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Reporter: Wolf-Dieter Fink
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink reassigned ISPN-6574:
--------------------------------------
Assignee: Galder Zamarreño
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created ISPN-6574:
--------------------------------------
Summary: JCache CacheManger need to know about existing caches if remote (HotRod) is used
Key: ISPN-6574
URL: https://issues.jboss.org/browse/ISPN-6574
Project: Infinispan
Issue Type: Bug
Reporter: Wolf-Dieter Fink
For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
Excerpt from API Doc:
------------------------------------
K,V> Cache<K,V> getCache(String cacheName,
Class<K> keyType,
Class<V> valueType)
Looks up a managed Cache given its name.
This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
Parameters:
cacheName - the name of the managed Cache to acquire
keyType - the expected Class of the key
valueType - the expected Class of the value
Returns:
the Cache or null if it does exist or can't be pre-configured
Throws:
IllegalStateException - if the CacheManager is isClosed()
IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6573) Functional API does not work [correctly] in transaction context
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-6573:
------------------------------------------
Summary: Functional API does not work [correctly] in transaction context
Key: ISPN-6573
URL: https://issues.jboss.org/browse/ISPN-6573
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.1.Final
Reporter: Krzysztof Sobolewski
Attachments: AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java
What is needed: a functional write operation on a key on a node that is not the key's owner, with cache loader enabled. What happens then is in non-transactional context it works fine; It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. The functional operation gets an empty entry even though the cache loader would load it. It then modifies the entry, but the modification is not propagated anywhere because the tx distribution interceptor... well, because it doesn't handle this command at all? And the change is (apparently) not committed on the local node because it's not an owner.
Oh, and if the node *is* an owner it doesn't help :)
The tests are also available at https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6518:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4287
> org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6518
> URL: https://issues.jboss.org/browse/ISPN-6518
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Priority: Critical
>
> The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
> The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
> Top heap consumers (final stage of the test)
> Class Instances Size(bytes) Percentage of Heap(%)
> byte[] 60,218 830,445,604 35.168
> Class Instances Size(bytes) Percentage of Heap(%)
> org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
> Transaction configuration:
> <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
> Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6518:
------------------------------
Status: Open (was: New)
> org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6518
> URL: https://issues.jboss.org/browse/ISPN-6518
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Priority: Critical
>
> The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
> The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
> Top heap consumers (final stage of the test)
> Class Instances Size(bytes) Percentage of Heap(%)
> byte[] 60,218 830,445,604 35.168
> Class Instances Size(bytes) Percentage of Heap(%)
> org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
> Transaction configuration:
> <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
> Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-6518:
-----------------------------------
{{DefaultPendingLockManager}} wasn't clean up transactions when the node is a backup owner only.
> org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6518
> URL: https://issues.jboss.org/browse/ISPN-6518
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Priority: Critical
>
> The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
> The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
> Top heap consumers (final stage of the test)
> Class Instances Size(bytes) Percentage of Heap(%)
> byte[] 60,218 830,445,604 35.168
> Class Instances Size(bytes) Percentage of Heap(%)
> org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
> Transaction configuration:
> <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
> Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6518:
------------------------------
Affects Version/s: 9.0.0.Alpha1
8.2.1.Final
8.1.3.Final
> org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6518
> URL: https://issues.jboss.org/browse/ISPN-6518
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Priority: Critical
>
> The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
> The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
> Top heap consumers (final stage of the test)
> Class Instances Size(bytes) Percentage of Heap(%)
> byte[] 60,218 830,445,604 35.168
> Class Instances Size(bytes) Percentage of Heap(%)
> org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
> Transaction configuration:
> <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
> Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo reassigned ISPN-6518:
---------------------------------
Assignee: Pedro Ruivo
> org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6518
> URL: https://issues.jboss.org/browse/ISPN-6518
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Priority: Critical
>
> The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
> The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
> Top heap consumers (final stage of the test)
> Class Instances Size(bytes) Percentage of Heap(%)
> byte[] 60,218 830,445,604 35.168
> Class Instances Size(bytes) Percentage of Heap(%)
> org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
> Class Instances Size(bytes) Percentage of Heap(%)
> java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
> Transaction configuration:
> <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
> Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years