[JBoss JIRA] (ISPN-4189) LevelDB module fails on Windows, Solaris and HP-UX machines
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-4189?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec reopened ISPN-4189:
---------------------------------------
> LevelDB module fails on Windows, Solaris and HP-UX machines
> -----------------------------------------------------------
>
> Key: ISPN-4189
> URL: https://issues.jboss.org/browse/ISPN-4189
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha3, 9.0.0.CR1
> Environment: Windows, Solaris
> Reporter: Vitalii Chepeliuk
> Assignee: Sebastian Łaskawiec
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 9.0.0.Final
>
> Attachments: JniLevelDBStoreFunctionalTest.log.zip
>
>
> Looks like some problems with loading LevelDB dynamic libraries via JNI
> Test suite progress: tests succeeded: 37, failed: 5, skipped: 0.
> org.infinispan.commons.CacheConfigurationException: Unable to instantiate class org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.Util.loadClass(Util.java:85)
> at org.infinispan.commons.util.Util.getInstance(Util.java:206)
> at org.infinispan.persistence.leveldb.LevelDBStore.newDbFactory(LevelDBStore.java:76)
> at org.infinispan.persistence.leveldb.LevelDBStore.init(LevelDBStore.java:59)
> at org.infinispan.persistence.leveldb.LevelDBStoreTest.createStore(LevelDBStoreTest.java:73)
> at org.infinispan.persistence.BaseStoreTest.setUp(BaseStoreTest.java:78)
> at sun.reflect.GeneratedMethodAccessor95.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.ClassNotFoundException: org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:135)
> at org.infinispan.commons.util.Util.loadClass(Util.java:83)
> ... 26 more
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.leveldbjni.JniDBFactory
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:122)
> ... 27 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7554) JGroupsTransport should expose the cluster view information atomically
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7554?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-7554:
------------------------------------
Example log:
{noformat}
15:22:12,525 INFO (testng-Test:[]) [JGroupsTransport] ISPN000094: Received new cluster view for channel ISPN: [Test-NodeM-31573|3] (4) [Test-NodeM-31573, Test-NodeN-49223, Test-NodeO-46628, Test-NodeP-46363]
15:22:12,683 TRACE (ForkThread-1,Test:[cluster-listener]) [StateTransferManagerImpl] StateTransferManager of cache cluster-listener on node Test-NodeP-46363 received initial topology CacheTopology{id=5, rebalanceId=3, currentCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeM-31573: 89+82, Test-NodeN-49223: 90+84, Test-NodeO-46628: 77+90]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeM-31573, Test-NodeN-49223, Test-NodeO-46628], persistentUUIDs=[bac87619-e272-4144-a501-c6f125bb3651, 24a62a07-8c3d-466c-9e2c-c23bdb13052d, 901123cc-cd87-4d75-8cd8-9e0da48fede8]}
15:22:12,683 TRACE (ForkThread-1,Test:[cluster-listener]) [JGroupsTransport] dests=[Test-NodeM-31573], command=CacheTopologyControlCommand{cache=cluster-listener, type=POLICY_GET_STATUS, sender=Test-NodeP-46363, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}, mode=SYNCHRONOUS, timeout=240000
15:22:12,683 TRACE (ForkThread-1,Test:[cluster-listener]) [LocalTopologyManagerImpl] Coordinator left the cluster while querying rebalancing status, retrying
15:22:12,683 TRACE (ForkThread-1,Test:[cluster-listener]) [JGroupsTransport] Waiting on view 5 being accepted
15:22:12,691 INFO (jgroups-4,Test-NodeP-46363:[]) [JGroupsTransport] ISPN000094: Received new cluster view for channel ISPN: [Test-NodeN-49223|4] (3) [Test-NodeN-49223, Test-NodeO-46628, Test-NodeP-46363]
{noformat}
> JGroupsTransport should expose the cluster view information atomically
> ----------------------------------------------------------------------
>
> Key: ISPN-7554
> URL: https://issues.jboss.org/browse/ISPN-7554
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> Currently the view is updated while holding a lock, but reading the view id, members, or coordinator is done without a lock. This means when a thread sends a request and receives a {{SuspectException}}, it cannot simply wait for a new view before retrying: the initial request may have used the latest view, and only the members list could be outdated (even if read later).
> To allow atomically reading the view id and the member list, we should use an immutable structure similar to {{CacheTopology}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7550) Remove TriangleAckInterceptor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7550?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7550:
------------------------------
Status: Open (was: New)
> Remove TriangleAckInterceptor
> -----------------------------
>
> Key: ISPN-7550
> URL: https://issues.jboss.org/browse/ISPN-7550
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Final
>
>
> {{TriangleAckInterceptor}} has 2 main goals
> 1. sends the from backup/primary to originator
> 2. in originator, waits for the acks
> ... and has 2 issues:
> 1. if an exception occurs before it, the ack will not be sent!
> 2. waiting for the acks here will add more complexity to the following interceptor if they need the operation outcome.
> So, by removing the interceptor will have:
> 1. acks are sent in inbound handler (where the replies are sent too)
> 2. waiting for ack will happen on {{TriangleDistributionInterceptor}}.
> Other changes:
> * before sending the ack, notify the {{TriangleOrderManager}} that the next command can proceed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7550) Remove TriangleAckInterceptor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7550?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7550:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4930
> Remove TriangleAckInterceptor
> -----------------------------
>
> Key: ISPN-7550
> URL: https://issues.jboss.org/browse/ISPN-7550
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Final
>
>
> {{TriangleAckInterceptor}} has 2 main goals
> 1. sends the from backup/primary to originator
> 2. in originator, waits for the acks
> ... and has 2 issues:
> 1. if an exception occurs before it, the ack will not be sent!
> 2. waiting for the acks here will add more complexity to the following interceptor if they need the operation outcome.
> So, by removing the interceptor will have:
> 1. acks are sent in inbound handler (where the replies are sent too)
> 2. waiting for ack will happen on {{TriangleDistributionInterceptor}}.
> Other changes:
> * before sending the ack, notify the {{TriangleOrderManager}} that the next command can proceed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7553) Replicated cache with numOwners=1 doesn't send writes to backups
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7553?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7553:
-------------------------------
Status: Open (was: New)
> Replicated cache with numOwners=1 doesn't send writes to backups
> ----------------------------------------------------------------
>
> Key: ISPN-7553
> URL: https://issues.jboss.org/browse/ISPN-7553
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 9.0.0.Final
>
>
> {{BaseDistributionInterceptor.primaryReturnHandler()}} doesn't replicate writes to the backups if {{cacheConfiguration.clustering().hash().numOwners() == 1}}. That check is incorrect, because a segment can have more owners than configured:
> 1. In a replicated cache, the configured {{numOwners}} is ignored, and all the members are owners.
> 1. Even in a distributed cache, during rebalance, the segments being moved will have more than {{numOwners}} owners.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7554) JGroupsTransport should expose the cluster view information atomically
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7554:
----------------------------------
Summary: JGroupsTransport should expose the cluster view information atomically
Key: ISPN-7554
URL: https://issues.jboss.org/browse/ISPN-7554
Project: Infinispan
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Dan Berindei
Currently the view is updated while holding a lock, but reading the view id, members, or coordinator is done without a lock. This means when a thread sends a request and receives a {{SuspectException}}, it cannot simply wait for a new view before retrying: the initial request may have used the latest view, and only the members list could be outdated (even if read later).
To allow atomically reading the view id and the member list, we should use an immutable structure similar to {{CacheTopology}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-4984) JdbcStringBasedStore with MySQL sets up column that uses case-insensitive comparisons for keys
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-4984?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-4984:
----------------------------------
Assignee: Ryan Emerson
> JdbcStringBasedStore with MySQL sets up column that uses case-insensitive comparisons for keys
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4984
> URL: https://issues.jboss.org/browse/ISPN-4984
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Randall Hauch
> Assignee: Ryan Emerson
>
> By default MySQL performs case-insensitive comparisons. This results in a problem when Infinispan entries use Strings that are distinct only in case-sensitive ways, since by default Infinispan's JdbcStringBasedStore (and maybe JdbcBinaryCacheStore) use {{VARCHAR(255)}} for the default {{idColumn}} type.
> This can of course be corrected in the Infinispan configuration. Rather than specifying this (which is equivalent to the default):
> {code}
> <idColumn name="ID_COLUMN" type="VARCHAR(255)"/>
> {code}
> the following can be specified instead:
> {code}
> <idColumn name="ID_COLUMN" type="VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci"/>
> {code}
> This will make MySQL perform case-sensitive comparisons and will work for all string keys.
> This enhancement request asks that the Infinispan JDBC-based stores use this by default so that it works automatically for MySQL users.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-4159:
----------------------------------
Assignee: Ryan Emerson (was: Adrian Nistor)
> DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4159
> URL: https://issues.jboss.org/browse/ISPN-4159
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> DefaultTwoWayKey2StringMapper uses two neat tricks.
> 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified.
> 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain.
> Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it.
> This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code.
> Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7469) Administration console - JDBC store elements have the same IDs
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7469?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7469:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> Administration console - JDBC store elements have the same IDs
> --------------------------------------------------------------
>
> Key: ISPN-7469
> URL: https://issues.jboss.org/browse/ISPN-7469
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR1
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Some elements have the same IDs.
> Steps to reproduce:
> Click on cache container -> cache -> configuration -> store -> select String keyed JDBC store -> click on String keyed table -> several input elements have the same ID
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month