[JBoss JIRA] (ISPN-11340) Upgrade JNA to 5.5.0
by Pedro Ruivo (Jira)
Pedro Ruivo created ISPN-11340:
----------------------------------
Summary: Upgrade JNA to 5.5.0
Key: ISPN-11340
URL: https://issues.redhat.com/browse/ISPN-11340
Project: Infinispan
Issue Type: Component Upgrade
Components: Test Suite
Affects Versions: 11.0.0.Alpha1, 10.1.2.Final
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 11.0.0.Beta1, 10.1.3.Final
testcontainers 1.12.5 uses JNA 5.5.0. Align with it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11004) SQL server exception purging data
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11004?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11004:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 11.0.0.Beta1
10.1.3.Final
9.4.19.Final
Resolution: Done
> SQL server exception purging data
> ---------------------------------
>
> Key: ISPN-11004
> URL: https://issues.redhat.com/browse/ISPN-11004
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.1.Final, 10.1.2.Final
> Reporter: Megan van de Valk
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Beta1, 10.1.3.Final, 9.4.19.Final
>
>
> When using string keyed jdbc store with dialect="SQL_SERVER" a SQL exception of 'FOR UPDATE clause allowed only for DECLARE CURSOR' is thrown.
> {code:java}
> 14:57:39,444 WARN [org.infinispan.PERSISTENCE] (expiration-thread--p7-t1) ISPN000026: Caught exception purging data container!: org.infinispan.persistence.spi.PersistenceException: Failed clearing string based JDBC store
> at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore.purge(JdbcStringBasedStore.java:502)
> at org.infinispan.persistence.spi.SegmentedAdvancedLoadWriteStore.purge(SegmentedAdvancedLoadWriteStore.java:291)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$purgeExpired$8(PersistenceManagerImpl.java:522)
> at java.util.ArrayList.forEach(ArrayList.java:1257)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.purgeExpired(PersistenceManagerImpl.java:528)
> at org.infinispan.persistence.support.DelegatingPersistenceManager.purgeExpired(DelegatingPersistenceManager.java:90)
> at org.infinispan.expiration.impl.ExpirationManagerImpl.processExpiration(ExpirationManagerImpl.java:120)
> at org.infinispan.expiration.impl.ExpirationManagerImpl$ScheduledTask.run(ExpirationManagerImpl.java:282)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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)
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR.
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:216)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1515)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:404)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:350)
> at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:5696)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1715)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:180)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:155)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(SQLServerPreparedStatement.java:285)
> at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore.purge(JdbcStringBasedStore.java:467)
> ... 14 more
> {code}
> The method initSelectOnlyExpiredRowsSql in [AbstractTableManager|https://github.com/infinispan/infinispan/blob/master...] includes a FOR UPDATE:
> {code:java}
> return String.format("%1$s WHERE %2$s < ? AND %2$s > 0 FOR UPDATE", getLoadAllRowsSql(), config.timestampColumnName());
> {code}
> It should probably be overwritten in [SQLServerTableManger|https://github.com/infinispan/infinispan/blob/master...] with
> {code:java}
> return String.format("%1$s WITH(UPDLOCK) WHERE %2$s < ? AND %2$s > 0", getLoadAllRowsSql(), config.timestampColumnName());
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-10292) It should be possible to add protobuf files directly to the server installation
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-10292?page=com.atlassian.jira.plugi... ]
Tristan Tarrant commented on ISPN-10292:
----------------------------------------
Schemas can also be ingested into a server using a CLI batch file.
> It should be possible to add protobuf files directly to the server installation
> -------------------------------------------------------------------------------
>
> Key: ISPN-10292
> URL: https://issues.redhat.com/browse/ISPN-10292
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Reporter: Wolf-Dieter Fink
> Priority: Major
> Labels: protobuf, query
>
> Definition files (protobuf) for queries and indexing need to be added with client requests during runtime.
> It will be stored in an internal cache and there is a persistence with a filestore to ensure it will survive restarts.
> But this is not always ensured as there might be catastropic failures or unclean shutdown which can cause inconsistence or complete loss.
> The behaviour in such cases is not deterministic and heavy to track or solve.
> For this reason it should be possible to add the protobuf definitions directly to the server installation which is picked up during startup.
> It might be a local cache as the expectation is that all nodes will have the same, but a repl cache might be possible as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11316) Split XSiteStateTransferControlCommand into individual commands
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11316?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11316:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Split XSiteStateTransferControlCommand into individual commands
> ---------------------------------------------------------------
>
> Key: ISPN-11316
> URL: https://issues.redhat.com/browse/ISPN-11316
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Beta1
>
>
> Currently the XSiteControlCommand uses a Type field and a switch statement to differentiate between various actions. This worked well for the old Externalizer approach, however it does not fit well with protobuf messages. Instead, the command should be split into individual commands.
> This enables the logic of the command types to be separated, making it easier to maintain backwards compatibility in the long term. Each command will use a ProtoStream TypeId in the range of 1000 -> 3999, so the cost of two bytes is the same as the existing class ID plus enum Type.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11291) MultipleCachesDuringConflictResolutionTest.testPartitionMergePolicy random failures
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11291?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11291:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> MultipleCachesDuringConflictResolutionTest.testPartitionMergePolicy random failures
> -----------------------------------------------------------------------------------
>
> Key: ISPN-11291
> URL: https://issues.redhat.com/browse/ISPN-11291
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.3.Final, 11.0.0.Alpha1
>
>
> Actually it fails pretty constantly in CI:
> {noformat}
> 18:59:06,673 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.MultipleCachesDuringConflictResolutionTest.testPartitionMergePolicy[DIST_SYNC, DENY_READ_WRITES]
> java.lang.RuntimeException: Cache Test timed out waiting for rebalancing to complete on node Test-NodeA, current topology is CacheTopology{id=8, phase=CONFLICT_RESOLUTION, rebalanceId=4, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeB: 256+0, Test-NodeA: 0+256]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeB, Test-NodeA], persistentUUIDs=[95c5afaf-de70-49f5-a494-4ae634425e9b, 73824c63-18cb-4de3-a714-b1b1b3fe5713]}. rebalanceInProgress=true, currentChIsBalanced=true
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:435) ~[test-classes/:?]
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:502) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePartitionHandlingTest$Partition.waitForPartitionToForm(BasePartitionHandlingTest.java:336) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePartitionHandlingTest$Partition.merge(BasePartitionHandlingTest.java:316) ~[test-classes/:?]
> at org.infinispan.partitionhandling.BasePartitionHandlingTest$Partition.merge(BasePartitionHandlingTest.java:305) ~[test-classes/:?]
> at org.infinispan.conflict.impl.MultipleCachesDuringConflictResolutionTest.testPartitionMergePolicy(MultipleCachesDuringConflictResolutionTest.java:60) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month