[JBoss JIRA] (ISPN-2115) Relative path in rhq ant task cause build to fail
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2115?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2115:
----------------------------------
Priority: Minor (was: Major)
> Relative path in rhq ant task cause build to fail
> -------------------------------------------------
>
> Key: ISPN-2115
> URL: https://issues.jboss.org/browse/ISPN-2115
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Reporter: Thomas Fromm
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 5.3.0.Final
>
>
> When the directory ../../ above the infinispan source dir is not writable,
> than build fails:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason
> [ERROR] around Ant part ...<mkdir dir="../../..//jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins"/>... @ 4:116 in /usr/local/inubit/tf/infinispan/rhq-plugin/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (deploy) on project infinispan-rhq-plugin: An Ant BuildException has occured: Directory /usr/local/inubit/jon/dev-container/jbossas/server/default/deploy/${rhq.earName}/rhq-downloads/rhq-plugins creation was not successful for an unknown reason
> In current case the /usr/local/inubit/ is not writable for the user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3089) The first write to a joiner in invalidation mode can be ignored
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3089?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3089:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1868
> The first write to a joiner in invalidation mode can be ignored
> ---------------------------------------------------------------
>
> Key: ISPN-3089
> URL: https://issues.jboss.org/browse/ISPN-3089
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final, 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> In invalidation mode we don't wait for the initial state transfer to finish, or even for the joiner to become a member in the "write" CH, before returning to the user from {{getCache()}}.
> Writes to the joiner before it becomes a member of the write CH are not committed to the local cache, because of a check in {{EntryWrappingInterceptor.shouldWrap()}}. So it's possible for the joiner to ignore the first write completely.
> If {{StateTransferConfigurationBuilder}} enabled {{awaitInitialTransfer}} by default in invalidation mode, like it does in distributed/replicated mode, this wouldn't happen.
> The fact that it will still be possible for the user to disable {{awaitInitialTransfer}} manually shouldn't be a problem, because in invalidation mode the user should expect values to be invalidated at any time. This is just about improving the default configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3089) The first write to a joiner in invalidation mode can be ignored
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3089?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3089:
-------------------------------
Description:
In invalidation mode we don't wait for the initial state transfer to finish, or even for the joiner to become a member in the "write" CH, before returning to the user from {{getCache()}}.
Writes to the joiner before it becomes a member of the write CH are not committed to the local cache, because of a check in {{EntryWrappingInterceptor.shouldWrap()}}. So it's possible for the joiner to ignore the first write completely.
If {{StateTransferConfigurationBuilder}} enabled {{awaitInitialTransfer}} by default in invalidation mode, like it does in distributed/replicated mode, this wouldn't happen.
The fact that it will still be possible for the user to disable {{awaitInitialTransfer}} manually shouldn't be a problem, because in invalidation mode the user should expect values to be invalidated at any time. This is just about improving the default configuration.
was:
In invalidation mode we don't wait for the initial state transfer to finish, or even for the joiner to become a member in the "write" CH, before returning to the user from {{getCache()}}.
Writes to the joiner before it becomes a member of the write CH are not committed to the local cache, because of a check in {{EntryWrappingInterceptor.shouldWrap()}}. So it's possible for the joiner to ignore the first write completely.
If {{StateTransferConfigurationBuilder}} enabled {{waitForInitialTransfer}} by default in invalidation mode, like it does in distributed/replicated mode, this wouldn't happen.
The fact that it will still be possible for the user to disable {{waitForInitialTransfer}} manually shouldn't be a problem, because in invalidation mode the user should expect values to be invalidated at any time. This is just about improving the default configuration.
> The first write to a joiner in invalidation mode can be ignored
> ---------------------------------------------------------------
>
> Key: ISPN-3089
> URL: https://issues.jboss.org/browse/ISPN-3089
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final, 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> In invalidation mode we don't wait for the initial state transfer to finish, or even for the joiner to become a member in the "write" CH, before returning to the user from {{getCache()}}.
> Writes to the joiner before it becomes a member of the write CH are not committed to the local cache, because of a check in {{EntryWrappingInterceptor.shouldWrap()}}. So it's possible for the joiner to ignore the first write completely.
> If {{StateTransferConfigurationBuilder}} enabled {{awaitInitialTransfer}} by default in invalidation mode, like it does in distributed/replicated mode, this wouldn't happen.
> The fact that it will still be possible for the user to disable {{awaitInitialTransfer}} manually shouldn't be a problem, because in invalidation mode the user should expect values to be invalidated at any time. This is just about improving the default configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3177) "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3177?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3177:
---------------------------------------
Hi Anna, does this happen only with an _async_ cachestore?
Could you attach the test?
> "Read past EOF" in case of using async fileStore with "infinispan" directory_provider
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3177
> URL: https://issues.jboss.org/browse/ISPN-3177
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory, Querying
> Affects Versions: 5.2.4.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Attachments: config.xml
>
>
> The cache configuration is attached (config.xml).
> While trying to run performance tests on the cache configured in the provided XML, i.e. performing parallel puts/gets with many threads (local mode), the following exception is thrown:
> Please note that exception is thrown on Put. I've changed the tests so that only one thread is run, but anyway this issue appears.
> If I comment the loader's part, then the test passes.
>
> {code}
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager query
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:169)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:149)
> at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:194)
> at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:225)
> at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:250)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:426)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:128)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:84)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infi^Cnispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:244)
> at org.radargun.cachewrappers.InfinispanExplicitLockingWrapper.put(InfinispanExplicitLockingWrapper.java:72)
> at org.radargun.cachewrappers.InfinispanQueryWrapper.put(InfinispanQueryWrapper.java:72)
> at org.radargun.stressors.StressTestStressor$FixedSetPerThreadOperationLogic.init(StressTestStressor.java:313)
> at org.radargun.stressors.StressTestStressor$Stressor.run(StressTestStressor.java:541)
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 33 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 36 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3179) The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3179?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3179:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> The server complains about missing memcachedCache even if the memcached-connector is configured to use a different one
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3179
> URL: https://issues.jboss.org/browse/ISPN-3179
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
> Attachments: standalone-compatibility-mode.xml
>
>
> Even if I use the following in the endpoint subsustem, the server complains that the memcachedCache is missing during startup:
> {code:xml}
> <memcached-connector socket-binding="memcached" cache-container="local" cache="default"/>
> {code}
> {code}
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.infinispan.local.memcachedCache (missing) dependents: [service jboss.endpoint.memcached.memcached-connector]
> 11:08:19,058 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 11:08:19,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 11:08:19,059 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started (with errors) in 2973ms - Started 88 of 124 services (1 services failed or missing dependencies, 35 services are passive or on-demand)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3163) Replacing entry via HotRod which was initially stored via Memcached does not change CAS
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3163?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3163:
----------------------------------------
I think this is a fair assumption, but a solution for this requires some thinking.
> Replacing entry via HotRod which was initially stored via Memcached does not change CAS
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3163
> URL: https://issues.jboss.org/browse/ISPN-3163
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Users might expect that CAS (check-and-set) operation will work even in compatibility mode which is currently not true in the following scenario:
> 1) store a key/value via Memcached
> 2) change the value via HotRod or Embedded
> 3) use Memcached's CAS operation
> In step #3 the memcached client will update the value even though the value was changed by another client in the meantime. The memcached client was supposed to change it only if it had not been changed in the meantime.
> The following test snippet shows the problem:
> {code:java}
> public void testMemcachedPutHotRodEmbbeddedReplaceMemcachedCASTest() throws Exception {
> final String key1 = "5";
> // 1. Put with Memcached
> Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v1");
> assertTrue(f.get(60, TimeUnit.SECONDS));
> CASValue oldValue = cacheFactory.getMemcachedClient().gets(key1);
> // 2. Replace with Hot Rod
> VersionedValue versioned = cacheFactory.getHotRodCache().getVersioned(key1);
> assertTrue(cacheFactory.getHotRodCache().replaceWithVersion(key1, "v2", versioned.getVersion()));
> // 3. Replace with Embedded
> assertTrue(cacheFactory.getEmbeddedCache().replace(key1, "v2", "v3"));
> // 4. Get with Memcached and verify value/CAS
> CASValue newValue = cacheFactory.getMemcachedClient().gets(key1);
> assertEquals("v3", newValue.getValue());
> assertTrue("The version (CAS) should have changed", oldValue.getCas() != newValue.getCas());
> //<---- fails here
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months