[JBoss JIRA] (ISPN-9307) State transfer should preserve the creation timestamp of entries
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created ISPN-9307:
--------------------------------------
Summary: State transfer should preserve the creation timestamp of entries
Key: ISPN-9307
URL: https://issues.jboss.org/browse/ISPN-9307
Project: Infinispan
Issue Type: Feature Request
Components: Core
Affects Versions: 6.0.1.Final
Reporter: Wolf-Dieter Fink
State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended.
The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (IPROTO-56) Dynamic entity support in MarshallerProvider
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/IPROTO-56?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated IPROTO-56:
------------------------------------
Summary: Dynamic entity support in MarshallerProvider (was: DynamicEntity support in MarshallerProvider)
> Dynamic entity support in MarshallerProvider
> --------------------------------------------
>
> Key: IPROTO-56
> URL: https://issues.jboss.org/browse/IPROTO-56
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Reporter: Gustavo Fernandes
>
> The use case is a class that describe the entity. This class contains a 'type' and a list of properties. MarshallerProvider is used to associate a type with a marshaller that uses this 'type' to understand the fields and data types to read/write the stream.
> The type of the entity is contained in the entity itself, and when reading from the stream, this type is used to figure out the fields to read. During writes, though, the type is not involved so it's not possible to use the same strategy.
> Attached is a unit test to illustrate the situation. This is not necessarily a bug, it may be possible to achieve the usage of Dynamic Entities under other circumstances, or maybe the API needs to be extended.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9306) Unguarded lazy initialization of SQL statements in JDBC CacheStore
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-9306:
-------------------------------------
Summary: Unguarded lazy initialization of SQL statements in JDBC CacheStore
Key: ISPN-9306
URL: https://issues.jboss.org/browse/ISPN-9306
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.3.0.CR1
Reporter: Sanne Grinovero
Assignee: Ryan Emerson
Several fields in {{org.infinispan.persistence.jdbc.table.management.AbstractTableManager}} are lazily initialized by its child implementations, yet without any barrier.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9287) Integration test suite fails when JAVA_HOME is not set
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9287?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-9287.
--------------------------------
Resolution: Done
> Integration test suite fails when JAVA_HOME is not set
> ------------------------------------------------------
>
> Key: ISPN-9287
> URL: https://issues.jboss.org/browse/ISPN-9287
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.3.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Final
>
>
> The build tries to run the {{kill-server}} Ant target before and after running the integration test suite. The target assumes that the server is running, and if none of ps/jps/lsof/netstat find the server it fails the build:
> {noformat}
> Caused by: org.apache.tools.ant.BuildException: The following error occurred while executing this line:
> /home/jenkins/workspace/polarion-report/5fee2853/server/integration/src/main/ant/infinispan-server.xml:102: Not yet supported on UNIX/WINDOWS favour without working ps/lsof/jps/netstat
> {noformat}
> Normally this doesn't happen because the {{jps}} check is not as strict as the others, passing if {{jps}} finds any java process (and not necessarily a server). But if {{JAVA_HOME}} is not defined, the {{jps}} check also fails:
> {noformat}
> [exec] Execute failed: java.io.IOException: Cannot run program "${env.JAVA_HOME}/bin/jps" (in directory "/home/jenkins/workspace/polarion-report/5fee2853/integrationtests/wildfly-modules"): error=2, No such file or directory
> {noformat}
> We should change the {{kill-server}} target so that it doesn't assume the server is already running. Maybe it could also use ps/jps to find the pid of the server, and lsof/netstat to check that the server really is really stopped after it was killed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9188) Cancelling the last segment doesn't remove transfer task
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-9188?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-9188.
--------------------------------
Resolution: Done
> Cancelling the last segment doesn't remove transfer task
> --------------------------------------------------------
>
> Key: ISPN-9188
> URL: https://issues.jboss.org/browse/ISPN-9188
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 9.3.0.Final
>
>
> If an {{InboundTransferTask}} has some completed segments and the last segment in an is cancelled with {{cancelSegments()}} (because the local node is no longer an owner), the task is never completed or removed from the list of active transfers.
> In the log below, NodeA adds segment 243 in topology 10. The transfer fails because NodeB shut down, so it's retried in topology 11 from NodeC.,
> {noformat}
> 13:19:17,057 TRACE (transport-thread-Test-NodeA-p22712-t2:[Topology-cluster-listener]) [StateConsumerImpl] Received new topology for cache cluster-listener, isRebalance = true, isMember = true, topology = CacheTopology{id=10, phase=READ_OLD_WRITE_ALL, rebalanceId=4, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[Test-NodeA-53146: 79+82, Test-NodeB-56589: 90+84, Test-NodeC-22289: 87+90]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeA-53146: 55+54, Test-NodeB-56589: 67+60, Test-NodeC-22289: 67+69, Test-NodeD-8561: 67+73]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeA-53146: 79+87, Test-NodeB-56589: 90+85, Test-NodeC-22289: 87+93, Test-NodeD-8561: 0+140]}, actualMembers=[Test-NodeA-53146, Test-NodeB-56589, Test-NodeC-22289, Test-NodeD-8561], persistentUUIDs=[dff2268e-e59e-48cc-809d-dcfe0774d1d8, 01379420-7999-4abf-abd8-2777454c035a, e9090b94-dc69-49d8-a2dc-ae0ad7f18fe0, 8edade14-6827-4b67-93d2-49b93844d8ad]}
> 13:19:17,097 TRACE (transport-thread-Test-NodeA-p22712-t2:[Topology-cluster-listener]) [StateConsumerImpl] On cache cluster-listener we have: added segments: {18 71 91-92 243}; removed segments: {}
> 13:19:17,097 TRACE (transport-thread-Test-NodeA-p22712-t2:[Topology-cluster-listener]) [StateConsumerImpl] Adding transfer from Test-NodeB-56589 for segments {18 71 91 243}
> 13:19:17,098 TRACE (transport-thread-Test-NodeA-p22712-t2:[Topology-cluster-listener]) [StateConsumerImpl] Adding transfer from Test-NodeC-22289 for segments {92}
> 13:19:17,107 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] Received new topology for cache cluster-listener, isRebalance = false, isMember = true, topology = CacheTopology{id=11, phase=READ_OLD_WRITE_ALL, rebalanceId=4, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeA-53146: 122+39, Test-NodeC-22289: 134+43]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeA-53146: 120+31, Test-NodeC-22289: 136+42]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeA-53146: 122+60, Test-NodeC-22289: 134+71]}, actualMembers=[Test-NodeA-53146, Test-NodeC-22289, Test-NodeD-8561], persistentUUIDs=[dff2268e-e59e-48cc-809d-dcfe0774d1d8, e9090b94-dc69-49d8-a2dc-ae0ad7f18fe0, 8edade14-6827-4b67-93d2-49b93844d8ad]}
> 13:19:17,140 TRACE (stateTransferExecutor-thread-Test-NodeA-p22713-t1:[StateRequest-cluster-listener]) [StateConsumerImpl] Inbound transfer finished: InboundTransferTask{segments={18 71 91 243}, finishedSegments={}, unfinishedSegments={18 71 91 243}, source=Test-NodeB-56589, isCancelled=false, completionFuture=java.util.concurrent.CompletableFuture@5237f653[Completed exceptionally], topologyId=10, timeout=240000, cacheName=cluster-listener}
> 13:19:17,156 TRACE (remote-thread-Test-NodeA-p22710-t5:[cluster-listener]) [StateConsumerImpl] Segments not received yet for cache cluster-listener: {Test-NodeB-56589=[InboundTransferTask{segments={18 71 91 243}, finishedSegments={}, unfinishedSegments={18 71 91 243}, source=Test-NodeB-56589, isCancelled=false, completionFuture=java.util.concurrent.CompletableFuture@5237f653[Completed exceptionally], topologyId=10, timeout=240000, cacheName=cluster-listener}]}
> 13:19:17,273 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] Removing inbound transfers from node Test-NodeB-56589 for segments {18 71 91 243}
> 13:19:17,274 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] Adding transfer from Test-NodeC-22289 for segments {18 71 91 243}
> 13:19:17,283 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] Received new topology for cache cluster-listener, isRebalance = true, isMember = true, topology = CacheTopology{id=12, phase=READ_OLD_WRITE_ALL, rebalanceId=5, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeA-53146: 122+39, Test-NodeC-22289: 134+43]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[Test-NodeA-53146: 76+78, Test-NodeC-22289: 90+80, Test-NodeD-8561: 90+98]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[Test-NodeA-53146: 122+75, Test-NodeC-22289: 134+73, Test-NodeD-8561: 0+188]}, actualMembers=[Test-NodeA-53146, Test-NodeC-22289, Test-NodeD-8561], persistentUUIDs=[dff2268e-e59e-48cc-809d-dcfe0774d1d8, e9090b94-dc69-49d8-a2dc-ae0ad7f18fe0, 8edade14-6827-4b67-93d2-49b93844d8ad]}
> 13:19:17,285 WARN (remote-thread-Test-NodeA-p22710-t6:[cluster-listener]) [StateConsumerImpl] Discarding received cache entries for segment 243 of cache cluster-listener because they do not belong to this node.
> 13:19:17,286 TRACE (remote-thread-Test-NodeA-p22710-t6:[cluster-listener]) [StateConsumerImpl] Segments not received yet for cache cluster-listener: {Test-NodeC-22289=[InboundTransferTask{segments={18 71 91 243}, finishedSegments={18 71 91}, unfinishedSegments={243}, source=Test-NodeC-22289, isCancelled=false, completionFuture=java.util.concurrent.CompletableFuture@2755cd[Not completed, 1 dependents], topologyId=11, timeout=240000, cacheName=cluster-listener}]}
> 13:19:17,428 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] On cache cluster-listener we have: added segments: {45 54-55 63 90 95-98 114-115 119 138-140 155-156 167 174-175 205 220-222}; removed segments: {30 66-67 77 93 190-192 243}
> 13:19:17,429 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [InboundTransferTask] Partially cancelling inbound state transfer from node Test-NodeC-22289, segments {243}
> 13:19:17,429 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] Adding transfer from Test-NodeC-22289 for segments {45 54-55 63 90 95-98 114-115 119 138-140 155-156 167 174-175 205 220-222}
> 13:19:17,430 TRACE (transport-thread-Test-NodeA-p22712-t1:[Topology-cluster-listener]) [StateConsumerImpl] notifyEndOfStateTransferIfNeeded: no active transfers
> {noformat}
> The last message is incorrect: the rebalance phase is not confirmed because there are 2 active transfers from NodeC: the 243 one, which wasn't completely cancelled, and the 45...222 one, which hasn't yet started.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-8533) Deadlock in pessimistic transaction
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8533?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-8533:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6075
> 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-5164) Deployment of marshallers on server
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5164?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-5164:
-------------------------------------
This issue does not say which marshaller, but if it's the compat mode marshaller we're talking about, that is already deployed in server.
So closing it as 'outdated' is more approppriate than' won't fix'
> Deployment of marshallers on server
> -----------------------------------
>
> Key: ISPN-5164
> URL: https://issues.jboss.org/browse/ISPN-5164
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Reporter: Tristan Tarrant
> Assignee: Galder Zamarreño
>
> It should be possible to deploy custom marshallers to the server so that they can be used e.g. in compatibility mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months