[JBoss JIRA] (ISPN-4651) LevelDB crashes JVM when stop() is called concurrently with write()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4651?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4651:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta2
Resolution: Done
> LevelDB crashes JVM when stop() is called concurrently with write()
> -------------------------------------------------------------------
>
> Key: ISPN-4651
> URL: https://issues.jboss.org/browse/ISPN-4651
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 7.0.0.Beta1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 7.0.0.Beta2
>
>
> This test reproduces the issue:
> {code}
> public void testConcurrentWriteAndRestart() {
> final int THREADS = 4;
> final AtomicBoolean run = new AtomicBoolean(true);
> final CountDownLatch started = new CountDownLatch(THREADS);
> ExecutorService executor = Executors.newFixedThreadPool(THREADS);
> for (int i = 0; i < THREADS; ++i) {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> started.countDown();
> int i = 0;
> while (run.get()) {
> InternalCacheEntry entry = TestInternalCacheEntryFactory.create("k" + i, "v" + i);
> MarshalledEntry me = TestingUtil.marshalledEntry(entry, getMarshaller());
> cl.write(me);
> ++i;
> }
> }
> });
> }
> try {
> started.await();
> Thread.sleep(1000);
> cl.stop();
> Thread.sleep(1000);
> cl.start();
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new IllegalStateException(e);
> } finally {
> run.set(false);
> executor.shutdown();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4654) AND over range queries does not work (indexless query)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4654?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4654:
-----------------------------------------------
Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1132121|https://bugzilla.redhat.com/show_bug.cgi?id=1132121] from ON_QA to ASSIGNED
> AND over range queries does not work (indexless query)
> ------------------------------------------------------
>
> Key: ISPN-4654
> URL: https://issues.jboss.org/browse/ISPN-4654
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying, Remote Querying
> Affects Versions: 6.0.2.Final, 7.0.0.Beta1
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
>
> Check this in QueryDslConditionsTest:
> {code}
> public void testAnd5() throws Exception {
> QueryFactory qf = getQueryFactory();
> // range queries use different code
> Query q = qf.from(getModelFactory().getUserImplClass())
> .having("id").lt(1000)
> .and().having("age").lt(1000)
> .toBuilder().build();
> List<User> list = q.list();
> assertEquals(3, list.size());
> }
> {code}
> The problem is that some subscription gets suspended and the second LT does not fire the second predicate update (and then neither the AND reevaluation).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4409) LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4409?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4409:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1108089|https://bugzilla.redhat.com/show_bug.cgi?id=1108089] from NEW to MODIFIED
> LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-4409
> URL: https://issues.jboss.org/browse/ISPN-4409
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5
>
>
> The LevelDBCacheStoreIT fails to start with an error resulting from initialising the server side cache marshaller. The way the cache manager is created is not correct. You might as well just use the same marshaller as for the client.
> Even if you really need a cache's marshaller, you should get it via an injected cache rather than initialising a cache from scratch.
> {code}com.arjuna.ats.arjuna.exceptions.FatalError: null
> at com.arjuna.ats.internal.jts.ORBManager.getPOA(ORBManager.java:96)
> at com.arjuna.ats.internal.jts.OTSImpleManager.<clinit>(OTSImpleManager.java:300)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.getTransaction(TransactionImple.java:1146)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple.getTransaction(TransactionManagerImple.java:69)
> at org.infinispan.cache.impl.CacheImpl.getOngoingTransaction(CacheImpl.java:1414)
> at org.infinispan.cache.impl.CacheImpl.getInvocationContextForRead(CacheImpl.java:592)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:474)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:469)
> at org.infinispan.registry.impl.ClusterRegistryImpl.keys(ClusterRegistryImpl.java:81)
> at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:67)
> at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132)
> at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:381)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.getServerMarshaller(LevelDBCacheStoreIT.java:190)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.<clinit>(LevelDBCacheStoreIT.java:67)
> « Hide stacktrace{code}
> The fix gets past this particular error but it still shows this afterwards:
> {code}Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport{code}
> Tristan is working on this...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4651) LevelDB crashes JVM when stop() is called concurrently with write()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4651?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4651:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1113585|https://bugzilla.redhat.com/show_bug.cgi?id=1113585] from ON_QA to VERIFIED
> LevelDB crashes JVM when stop() is called concurrently with write()
> -------------------------------------------------------------------
>
> Key: ISPN-4651
> URL: https://issues.jboss.org/browse/ISPN-4651
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 7.0.0.Beta1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> This test reproduces the issue:
> {code}
> public void testConcurrentWriteAndRestart() {
> final int THREADS = 4;
> final AtomicBoolean run = new AtomicBoolean(true);
> final CountDownLatch started = new CountDownLatch(THREADS);
> ExecutorService executor = Executors.newFixedThreadPool(THREADS);
> for (int i = 0; i < THREADS; ++i) {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> started.countDown();
> int i = 0;
> while (run.get()) {
> InternalCacheEntry entry = TestInternalCacheEntryFactory.create("k" + i, "v" + i);
> MarshalledEntry me = TestingUtil.marshalledEntry(entry, getMarshaller());
> cl.write(me);
> ++i;
> }
> }
> });
> }
> try {
> started.await();
> Thread.sleep(1000);
> cl.stop();
> Thread.sleep(1000);
> cl.start();
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new IllegalStateException(e);
> } finally {
> run.set(false);
> executor.shutdown();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-417) AtomicHashMap Externalizer returns delta and not hash map on deserialization
by Paris Apostolopoulos (JIRA)
[ https://issues.jboss.org/browse/ISPN-417?page=com.atlassian.jira.plugin.s... ]
Paris Apostolopoulos commented on ISPN-417:
-------------------------------------------
Is the issue valid on infinispan 6.0.2 (wildfly 8.1?)
Caused by: java.lang.ClassCastException: org.infinispan.atomic.AtomicHashMapDelta cannot be cast to org.infinispan.atomic.AtomicHashMap
> AtomicHashMap Externalizer returns delta and not hash map on deserialization
> ----------------------------------------------------------------------------
>
> Key: ISPN-417
> URL: https://issues.jboss.org/browse/ISPN-417
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Marshalling
> Affects Versions: 4.0.0.Final, 4.1.0.ALPHA3
> Reporter: Manik Surtani
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 4.1.0.BETA1
>
>
> AtomicHashMap Externalizer should merge deserialized delta into an atomic hash map and return that, rather than returning a delta.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4637) HotRodServer allows registration of ClientListener which specifies non-existing 'converterFactoryName'
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4637?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4637:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2794, https://github.com/infinispan/infinispan/pull/2817 (was: https://github.com/infinispan/infinispan/pull/2794)
> HotRodServer allows registration of ClientListener which specifies non-existing 'converterFactoryName'
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4637
> URL: https://issues.jboss.org/browse/ISPN-4637
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 7.0.0.Beta1
> Environment: Mac OS X 10.9.4, Oracle HotSpot 1.7.0_67. Infinispan built from master.
> Reporter: Duncan Doyle
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta2
>
>
> The HotRodServer allows for the registration of custom ClientListeners that specify a non-existing 'converterFactoryName'. I.e., the ClientListenerRegistry.addClientListener method/function does not check whether the given 'converterFactoryName' exists on the server, and if it doesn't exist, it adds the ClientListener with a Null converter.
> The problem is that this gives unexpected results in the client. ISPN in this case seems to send back events that just contain the 'value' of the entry that was inserted/modified/removed. But the ClientListener probably expects a custom type: ClientCacheEntryCustomEvent<MyCustomType>
> So, eventually what happens is funky CCEs because the eventData returned in the event (in this case the value of the entry) is not of the same class as MyCustomType.
> In my opinion, HotRodServer should return an error when one tries to register a listener which specifies a non-registered converterFactory.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-1261) Complete the work on the event bridge between Infinispan and CDI
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1261?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1261:
-----------------------------------
Assignee: Sebastian Łaskawiec (was: Kevin Pollet)
> Complete the work on the event bridge between Infinispan and CDI
> ----------------------------------------------------------------
>
> Key: ISPN-1261
> URL: https://issues.jboss.org/browse/ISPN-1261
> Project: Infinispan
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: CDI Integration
> Reporter: Kevin Pollet
> Assignee: Sebastian Łaskawiec
>
> The event bridge (for cache and cache manager) is already implemented in the code but some events are not supported and a deprecated one is used. The following work has to be done on the event bridge:
> * Remove deprecated event
> * Support all events
> * Verify how cache and cache manager observers are registered
> * Tests
> * Doc
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3979:
-------------------------------------
Would using the global configuration to load the class be acceptable for you?
> JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
> -------------------------------------------------------------------------
>
> Key: ISPN-3979
> URL: https://issues.jboss.org/browse/ISPN-3979
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores
> Affects Versions: 6.0.1.Final
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance?
> I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months