Fehler beim Deserialisieren Ausnahme Antwort von stream - Grails ElasticSearch

Habe ich eine einfache Grails-app, die ich bin, die versuchen, upo nutzen ElasticSearch.

Ich habe eine single-node-ElasticSearch-Instanz in EC2 ausgeführten, die sich glücklich genug. (Als Referenz, ich folgte den Schritten hier: http://www.elasticsearch.org/tutorials/elasticsearch-on-ec2/), aber mit 0.90.7 und das cloud-aws plugin-version 1.15.0)

Ich bin mit dem Grails ElasticSearch GORM plugin (http://grails.org/plugin/elasticsearch-gorm) (Master-branch) und ich bin die Verbindung zu LiveCycle ES mithilfe der transport-client-Modus (elasticSearch.client.mode = "transport")

Hier wird es wirklich seltsam...

Als ich das erste mal Booten, bis meine app, es wird fröhlich index meine Domain-Daten, die auf ES, ich kann eine Abfrage, etc, keine Probleme.

Wenn ich dann neu starten, mein grails-app, es wird nicht starten. Ich bekomme

Meldung: Fehler beim erstellen bean mit dem Namen 'searchableClassMappingConfigurator': Aufruf der init-Methode fehlgeschlagen; verschachtelte Ausnahme ist org.elasticsearch.transport.TransportSerializationException: Fehler beim Deserialisieren Ausnahme Antwort von stream

    Line | Method
->>  262 | run       in java.util.concurrent.FutureTask
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|   1145 | runWorker in java.util.concurrent.ThreadPoolExecutor
|    615 | run . . . in java.util.concurrent.ThreadPoolExecutor$Worker
^    724 | run       in java.lang.Thread
Caused by TransportSerializationException: Failed to deserialize exception response from stream
->>  169 | handlerResponseError in org.elasticsearch.transport.netty.MessageChannelHandler
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|    123 | messageReceived in     ''
|     70 | handleUpstream in org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler
|    564 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline
|    791 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext
|    296 | fireMessageReceived in org.elasticsearch.common.netty.channel.Channels
|    462 | unfoldAndFireMessageReceived in org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder
|    443 | callDecode in     ''
|    310 | messageReceived in     ''
|     70 | handleUpstream in org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler
|    564 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline
|    559 | sendUpstream in     ''
|    268 | fireMessageReceived in org.elasticsearch.common.netty.channel.Channels
|    255 | fireMessageReceived in     ''
|     88 | read . .  in org.elasticsearch.common.netty.channel.socket.nio.NioWorker
|    108 | process   in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker
|    318 | run . . . in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector
|     89 | run       in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker
|    178 | run . . . in org.elasticsearch.common.netty.channel.socket.nio.NioWorker
|    108 | run       in org.elasticsearch.common.netty.util.ThreadRenamingRunnable
|     42 | run . . . in org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1
|   1145 | runWorker in java.util.concurrent.ThreadPoolExecutor
|    615 | run . . . in java.util.concurrent.ThreadPoolExecutor$Worker
^    724 | run       in java.lang.Thread
Caused by StreamCorruptedException: unexpected end of block data
->> 1370 | readObject0 in java.io.ObjectInputStream
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|   1989 | defaultReadFields in     ''
|    499 | defaultReadObject in     ''
|    914 | readObject in java.lang.Throwable
|   1017 | invokeReadObject in java.io.ObjectStreamClass
|   1891 | readSerialData in java.io.ObjectInputStream
|   1796 | readOrdinaryObject in     ''
|   1348 | readObject0 in     ''
|   1989 | defaultReadFields in     ''
|    499 | defaultReadObject in     ''
|    914 | readObject in java.lang.Throwable
|   1017 | invokeReadObject in java.io.ObjectStreamClass
|   1891 | readSerialData in java.io.ObjectInputStream
|   1796 | readOrdinaryObject in     ''
|   1348 | readObject0 in     ''
|    370 | readObject in     ''
|    167 | handlerResponseError in org.elasticsearch.transport.netty.MessageChannelHandler
|    123 | messageReceived in     ''
|     70 | handleUpstream in org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler
|    564 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline
|    791 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext
|    296 | fireMessageReceived in org.elasticsearch.common.netty.channel.Channels
|    462 | unfoldAndFireMessageReceived in org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder
|    443 | callDecode in     ''
|    310 | messageReceived in     ''
|     70 | handleUpstream in org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler
|    564 | sendUpstream in org.elasticsearch.common.netty.channel.DefaultChannelPipeline
|    559 | sendUpstream in     ''
|    268 | fireMessageReceived in org.elasticsearch.common.netty.channel.Channels
|    255 | fireMessageReceived in     ''
|     88 | read . .  in org.elasticsearch.common.netty.channel.socket.nio.NioWorker
|    108 | process   in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker
|    318 | run . . . in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector
|     89 | run       in org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker
|    178 | run . . . in org.elasticsearch.common.netty.channel.socket.nio.NioWorker
|    108 | run       in org.elasticsearch.common.netty.util.ThreadRenamingRunnable
|     42 | run . . . in org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1
|   1145 | runWorker in java.util.concurrent.ThreadPoolExecutor
|    615 | run . . . in java.util.concurrent.ThreadPoolExecutor$Worker
^    724 | run       in java.lang.Thread

Dies geschieht solange, bis ich die elasticSearch-host-details - sprich, ich kann nicht Booten mein ap an alle, mit dem original-host-details, immer und immer wieder.

Beide das ES Knoten und meine Grails-app sind sowohl mit elasticSearch 0.90.7, meine config mit der ES-plugin sieht so aus:@

elasticSearch.client.mode = 'transport'
elasticSearch.client.hosts = [[host:'<my EC2 DNS>', port:9300]]
elasticSearch.datastoreImpl = 'mongoDatastore'
elasticSearch.client.transport.sniff = true

Der domain nur Objekt bin ich die Kennzeichnung als "durchsuchbare" zugeordnet ist, mit mongoDB, die sieht so aus:

class CompletedApplicationFormSearchEntry {
    static searchable = true
    Long formId
    Long jobId
    Long employerId
    Long jobseekerId
    Date applicationDate

    static mapWith = "mongo"

    static constraints = {
    }
}

Wenn ich entfernen Sie die durchsuchbaren attribute aus der domain Klasse, dann die app neu starten, es startet gut, also gehe ich davon aus, dass es etwas Los in der bootstrapping-Prozess, wenn das domain-Objekt erkannt wird als durchsuchbare, aber natürlich, es verursacht nur ein Problem, wenn die app neu gestartet wurde.

Gibt es eine Handvoll threads treten, wo Menschen zu sehen sind, ähnliches Problem,wo Sie Knoten unter ES verschiedene Versionen, verschiedene JVM-version,s usw. Aber in diesem Fall habe ich nur einen Knoten haben!

Bin ich absolut zu reißen meine Haare aus über diese - ich kann einfach nicht herausfinden, was auf der Erde schief geht. Ich habe versucht, verschiedene plugin-Versionen, elasticsearch Versionen, 32-bit-EC2-Instanz 64bit EC2-instance - kein Glück!

Stellen Sie sicher, dass Sie in der JVM-Versionen, die identisch sind zwischen den ES-Knoten und die Grails-Anwendung. Die transport-Knoten kommuniziert mit dem cluster über das Binär-Protokoll, und der Teil basiert auf der Serialisierung von Ausnahmen in Java. Leider, java änderungen diese Serialisierung zwischen den Versionen, und manchmal können Sie sehen, von Ausnahmen wie dem ihrigen.
Die JVM-Versionen waren identisch, das Problem war tatsächlich mit der Grails-plugin und das ElasticSearch-jar-version. Das Grails-plugin übernimmt keine überprüfung auf, wenn ein index bereits erstellt wurde, bevor Sie versuchen, es zu schaffen.... also das erste mal, wenn Sie eine Verbindung zu elasticsearch es gut läuft, dann ist jede Zeit, nachdem es eine Ausnahme auslöst. Ich war mit elastic search 0.90.7, die wirft ein TransportSerializationException, das war nie gefangen. Ich habe einen pull-request für ein Update: github.com/mstein/elasticsearch-grails-plugin/pull/74
Vorschlag der identischen JVM-version für mich funktionierte.

InformationsquelleAutor Jiminyjetson | 2013-11-22

elasticsearch grails

0

Sieht aus wie es war ein Problem mit dem plugin mit Elasticsearch 0.90.7 werfen eine exception, die nicht gefangen von dem plugin.

Pull-request hier: https://github.com/mstein/elasticsearch-grails-plugin/pull/74 hat ein Update und schließt ES 0.90.7

InformationsquelleAutor Jiminyjetson

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.