[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3685?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3685:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3685
> URL: https://issues.jboss.org/browse/ISPN-3685
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Pedro Ruivo
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster:
> java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766)
> ... 4 more
> This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific.
--
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, 1 month
[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3376:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> CLI upgrade command does not work
> ---------------------------------
>
> Key: ISPN-3376
> URL: https://issues.jboss.org/browse/ISPN-3376
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml
>
>
> Run my backup server with default standalone.xml configuration
> ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER
> Run my new server with
> ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER
> 1) run command on BACKUPER
> [remoting://localhost:10110/local/default]> upgrade --dumpkeys default
> ISPN019502: Dumped keys for cache default
> 2) run command on UPGRADER
> [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default
> ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server
--
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, 1 month
[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3048:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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, 1 month
[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3335:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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, 1 month
[JBoss JIRA] (ISPN-3621) Most CacheStore configuration examples in the documentation are wrong (outdated)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3621?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3621:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> Most CacheStore configuration examples in the documentation are wrong (outdated)
> --------------------------------------------------------------------------------
>
> Key: ISPN-3621
> URL: https://issues.jboss.org/browse/ISPN-3621
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Fix For: 6.1.0.Final
>
>
> I've been trying half a dozen configuration snippets from the documentation, I couldn't get any CacheStore to work. All I get from the configuration parser is an unhelpfull stack trace:
> {quote}
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[50,63]
> Message: Unexpected element '{urn:infinispan:config:6.0}loaders' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:35)
> at org.infinispan.configuration.parsing.Parser60.parseCache(Parser60.java:178)
> at org.infinispan.configuration.parsing.Parser60.parseNamedCache(Parser60.java:109)
> at org.infinispan.configuration.parsing.Parser60.readElement(Parser60.java:76)
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:130)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:112)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:99)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:86)
> ... 47 more
> {quote}
> One might think that something (what?) is wrong at [row,col]:[50,63] but I'm copy pasting the documentation.
--
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, 1 month
[JBoss JIRA] (ISPN-2958) Lucene Directory Read past EOF
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2958:
--------------------------------
Fix Version/s: 6.1.0.Final
(was: 6.0.0.Final)
> Lucene Directory Read past EOF
> ------------------------------
>
> Key: ISPN-2958
> URL: https://issues.jboss.org/browse/ISPN-2958
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.1.Final
> Reporter: Clement Pang
> Assignee: Pedro Ruivo
> Labels: retest, stable_embedded_query
> Fix For: 6.1.0.Final
>
>
> This seems to be happening rather deterministically.
> Infinispan configuration (in JBoss EAP 6.1.0.Alpha):
> {code}
> <cache-container name="lucene">
> <local-cache name="dshell-index-data" start="EAGER">
> <eviction strategy="LIRS" max-entries="50000"/>
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-metadata" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-lock" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> </cache-container>
> {code}
> Upon shutting down the server and confirming that passivation did indeed write the data to disk, the subsequent start-up would fail right away with:
> {code}
> 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)
> ... 64 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)
> ... 67 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, 1 month