[JBoss JIRA] (ISPN-1680) Remove SKIP_LOCK flags from Lucene Directory where no longer needed
by Joseph MacFarlane (JIRA)
[ https://issues.jboss.org/browse/ISPN-1680?page=com.atlassian.jira.plugin.... ]
Joseph MacFarlane commented on ISPN-1680:
-----------------------------------------
We're currently using 4.2.1 (and production instances will continue to do so for the foreseeable future). We found that retrofitting this fix resolved 'Read past EOF' errors arising from high volumes of simultaneous search and update with the following stack trace:
{code}
...
Caused by: org.hibernate.search.SearchException: Unable to reopen IndexReader
at org.hibernate.search.reader.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:268)
at org.hibernate.search.reader.SharingBufferReaderProvider.openReader(SharingBufferReaderProvider.java:146)
...
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:40)
at org.apache.lucene.store.IndexInput.readInt(IndexInput.java:71)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:260)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:350)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:736)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346)
at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:462)
at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:875)
at org.apache.lucene.index.DirectoryReader.doReopenNoWriter(DirectoryReader.java:441)
at org.apache.lucene.index.DirectoryReader.doReopen(DirectoryReader.java:420)
at org.apache.lucene.index.DirectoryReader.reopen(DirectoryReader.java:378)
at org.hibernate.search.reader.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:265)
... 83 more
{code}
> Remove SKIP_LOCK flags from Lucene Directory where no longer needed
> -------------------------------------------------------------------
>
> Key: ISPN-1680
> URL: https://issues.jboss.org/browse/ISPN-1680
> Project: Infinispan
> Issue Type: Task
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Fix For: 5.1.0.CR3
>
>
--
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, 8 months
[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2281:
-----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/1790
> Enable inter server endpoint communication in a compatibility mode
> ------------------------------------------------------------------
>
> Key: ISPN-2281
> URL: https://issues.jboss.org/browse/ISPN-2281
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode.
> Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator.
> When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well).
> For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above.
> May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?).
> In-VM may need registration of an Externalizer?
--
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, 8 months