[JBoss JIRA] (ISPN-8533) Deadlock in pessimistic transaction
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8533?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8533:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Deadlock in pessimistic transaction
> -----------------------------------
>
> Key: ISPN-8533
> URL: https://issues.jboss.org/browse/ISPN-8533
> Project: Infinispan
> Issue Type: Bug
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Final
>
>
> Deadlock can happen (not sure how) during a topology change and pessimistic transaction.
> 2 transaction can end up in the pending lock manager and they will wait for each other to finish.
> {noformat}
> Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-a:3746. Current owner GlobalTx:node-b:3629.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> {noformat}
> {noformat}
> Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-b:3629. Current
> owner GlobalTx:node-a:3746.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.
> jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
> {noformat}
> notes: confirm the pending lock manager is cleanup!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9286) WriteBehindFaultToleranceTest Failures
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9286?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-9286.
--------------------------------
Resolution: Done
> WriteBehindFaultToleranceTest Failures
> --------------------------------------
>
> Key: ISPN-9286
> URL: https://issues.jboss.org/browse/ISPN-9286
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 9.3.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Final
>
>
> #testBlockingOnStoreAvailabilityChange failure due to the async write not completing before store.size is called.
> {code:java}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.infinispan.persistence.WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange(WriteBehindFaultToleranceTest.java:55)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 23 stack frames
> {code}
> #testWritesFailSilentlyWhenConfigured failure due to the async write not being executed on the store before the entry is loaded from the store.
> {code:java}
> java.lang.NullPointerException
> at org.infinispan.persistence.WriteBehindFaultToleranceTest.testWritesFailSilentlyWhenConfigured(WriteBehindFaultToleranceTest.java:110)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 18 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ]
Marek Posolda commented on ISPN-9323:
-------------------------------------
NOTE: This is regression of infinispan server 9. When I used JDG 7.2 server or infinispan-server-8.2.8.Final, I wasn't able to reproduce the issue. Both "created" and "lastUsed" where correctly set. Also the issue can be reproduced just with transactional caches.
> RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-9323
> URL: https://issues.jboss.org/browse/ISPN-9323
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Server
> Affects Versions: 9.3.0.CR1, 9.2.4.Final
> Reporter: Marek Posolda
> Attachments: RemoteCacheExpirationTest.java
>
>
> I have transactional cache defined on server side (infinispan-server). I have HotRod client application (RemoteCache), which is connected to server above and which calls this:
> {code}
> remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
> MetadataValue loaded = remoteCache.getWithMetadata("key");
> System.out.println("created: " + loaded.getCreated() + ", lastUsed: " + loaded.getLastUsed());
> {code}
> The output is:
> {code}
> created: 0, lastUsed: 0
> {code}
> This is not correct and causes some issues as entries are treated as expired. Especially when used together with remote-store, which is not able to load such entries, as PersistenceUtil#loadAndCheckExpiration method always treat the item loaded from RemoteCache as expired. See the attached application for more details.
> STEPS TO REPRODUCE:
> 1) Use infinispan-server-9.2.4.Final on server side and HotRod client (RemoteCache) version 9.2.4.Final on client side (maven dependency org.infinispan:infinispan-client-hotrod:9.2.4.Final for client app)
> 2) Unzip server 9.2.4.Final to some directory
> 3) Change ISPN_SERVER_HOME/standalone/configuration/clustered.xml and just add this transactional cache to the cache-container (NOTE: configuration "transactional" is already defined in the clustered.xml file):
> {code}
> <distributed-cache name="trans" configuration="transactional" />
> {code}
> 4) Run server with:
> {code}
> ./standalone.sh -c clustered.xml
> {code}
> 5) Run the client application from attachement. You can see the output as described above and also that entry is considered as expired (Example app uses same algorithm like RemoteStore together with PersistenceUtil.loadAndCheckExpired ). Original sources here: https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ]
Marek Posolda updated ISPN-9323:
--------------------------------
Attachment: RemoteCacheExpirationTest.java
> RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-9323
> URL: https://issues.jboss.org/browse/ISPN-9323
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Server
> Affects Versions: 9.3.0.CR1, 9.2.4.Final
> Reporter: Marek Posolda
> Attachments: RemoteCacheExpirationTest.java
>
>
> I have transactional cache defined on server side (infinispan-server). I have HotRod client application (RemoteCache), which is connected to server above and which calls this:
> {code}
> remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
> MetadataValue loaded = remoteCache.getWithMetadata("key");
> System.out.println("created: " + loaded.getCreated() + ", lastUsed: " + loaded.getLastUsed());
> {code}
> The output is:
> {code}
> created: 0, lastUsed: 0
> {code}
> This is not correct and causes some issues as entries are treated as expired. Especially when used together with remote-store, which is not able to load such entries, as PersistenceUtil#loadAndCheckExpiration method always treat the item loaded from RemoteCache as expired. See the attached application for more details.
> STEPS TO REPRODUCE:
> 1) Use infinispan-server-9.2.4.Final on server side and HotRod client (RemoteCache) version 9.2.4.Final on client side (maven dependency org.infinispan:infinispan-client-hotrod:9.2.4.Final for client app)
> 2) Unzip server 9.2.4.Final to some directory
> 3) Change ISPN_SERVER_HOME/standalone/configuration/clustered.xml and just add this transactional cache to the cache-container (NOTE: configuration "transactional" is already defined in the clustered.xml file):
> {code}
> <distributed-cache name="trans" configuration="transactional" />
> {code}
> 4) Run server with:
> {code}
> ./standalone.sh -c clustered.xml
> {code}
> 5) Run the client application from attachement. You can see the output as described above and also that entry is considered as expired (Example app uses same algorithm like RemoteStore together with PersistenceUtil.loadAndCheckExpired ). Original sources here: https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by Marek Posolda (JIRA)
Marek Posolda created ISPN-9323:
-----------------------------------
Summary: RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
Key: ISPN-9323
URL: https://issues.jboss.org/browse/ISPN-9323
Project: Infinispan
Issue Type: Bug
Components: Hot Rod, Server
Affects Versions: 9.2.4.Final, 9.3.0.CR1
Reporter: Marek Posolda
I have transactional cache defined on server side (infinispan-server). I have HotRod client application (RemoteCache), which is connected to server above and which calls this:
{code}
remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
MetadataValue loaded = remoteCache.getWithMetadata("key");
System.out.println("created: " + loaded.getCreated() + ", lastUsed: " + loaded.getLastUsed());
{code}
The output is:
{code}
created: 0, lastUsed: 0
{code}
This is not correct and causes some issues as entries are treated as expired. Especially when used together with remote-store, which is not able to load such entries, as PersistenceUtil#loadAndCheckExpiration method always treat the item loaded from RemoteCache as expired. See the attached application for more details.
STEPS TO REPRODUCE:
1) Use infinispan-server-9.2.4.Final on server side and HotRod client (RemoteCache) version 9.2.4.Final on client side (maven dependency org.infinispan:infinispan-client-hotrod:9.2.4.Final for client app)
2) Unzip server 9.2.4.Final to some directory
3) Change ISPN_SERVER_HOME/standalone/configuration/clustered.xml and just add this transactional cache to the cache-container (NOTE: configuration "transactional" is already defined in the clustered.xml file):
{code}
<distributed-cache name="trans" configuration="transactional" />
{code}
4) Run server with:
{code}
./standalone.sh -c clustered.xml
{code}
5) Run the client application from attachement. You can see the output as described above and also that entry is considered as expired (Example app uses same algorithm like RemoteStore together with PersistenceUtil.loadAndCheckExpired ). Original sources here: https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9181) Remove compat mode from Remote Iterator
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9181?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9181:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.0.Final
Resolution: Done
> Remove compat mode from Remote Iterator
> ---------------------------------------
>
> Key: ISPN-9181
> URL: https://issues.jboss.org/browse/ISPN-9181
> Project: Infinispan
> Issue Type: Sub-task
> Components: Server
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.3.0.Final
>
>
> The remote iterator has internal checks for compat mode and unmarshalls keys and values before running them to the filters (in case they're present).
> There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where each listener control the type of data should receive, either as Pojos or binary format.
> Furthermode, there is a Cache Manager wide marshaller that is used to "unmarshall" filter paramers and objects. This marshaller should be removed and instead the MediaType info sent by clients should be used to select the right transcoder to convert to/from the storage format
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9184) Remove compat mode from Remote Listener
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9184?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9184:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.0.Final
Resolution: Done
> Remove compat mode from Remote Listener
> ---------------------------------------
>
> Key: ISPN-9184
> URL: https://issues.jboss.org/browse/ISPN-9184
> Project: Infinispan
> Issue Type: Sub-task
> Components: Listeners
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.3.0.Final
>
>
> Remote Listeners uses compat mode checks in plenty of places to convert between storage and pojo format, and apart from that, there is a cache manager wide "event marshaller" used to unmarshal params for filters used in events, falling back to GenericJbossMarshaller when the marshaller is not set.
> It should not use a global marshaller and should not hardcode JbossMarshaller, instead the remote listener themselves should have a mechanism of choosing the format of the data, similar to "useRawData" (where one can choose to receive events in a marshalled or unmarshaled way). One way of doing it is to supply a MediaType in the listener with the desired format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (HRJS-65) Document handling Promise leaks
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-65:
------------------------------------
Summary: Document handling Promise leaks
Key: HRJS-65
URL: https://issues.jboss.org/browse/HRJS-65
Project: Infinispan Javascript client
Issue Type: Task
Reporter: Galder Zamarreño
Using promises can lead to leaks. This are currently either resolved using recent Node.js platform versions that have native promise handling, or by generating one extra promise instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9180) Remove compat mode from Remote Query
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9180?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9180:
------------------------------------
Status: Open (was: New)
> Remove compat mode from Remote Query
> ------------------------------------
>
> Key: ISPN-9180
> URL: https://issues.jboss.org/browse/ISPN-9180
> Project: Infinispan
> Issue Type: Sub-task
> Components: Remote Querying
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
> The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the incoming content to java object (String) on the fly, as long as the server supports conversion between the content produced by marshaller and java object.
> Apart from that, there are multiple places in the code that registers/instantiates/configures objects based on the compat mode marshaller, and assume all content will be unmarshalled by this marshaller. It should instead rely on the MediaType information sent by the HR client and do the conversion on the fly, this would allow indexing and querying in multiple formats as long as the storage format is supported and the conversion between the input/storage is supported by the server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months