Caused by: java.util.NoSuchElementException: Sequence contains no elements
at rx.internal.operators.OperatorSingle$ParentSubscriber.onCompleted(OperatorSingle.java:115)
at rx.internal.operators.OperatorMerge$MergeSubscriber.emitLoop(OperatorMerge.java:656)
at rx.internal.operators.OperatorMerge$MergeSubscriber.emit(OperatorMerge.java:568)
at rx.internal.operators.OperatorMerge$InnerSubscriber.onCompleted(OperatorMerge.java:857)
at rx.internal.operators.OperatorZip$Zip.tick(OperatorZip.java:239)
at rx.internal.operators.OperatorZip$Zip$InnerSubscriber.onCompleted(OperatorZip.java:307)
at rx.internal.operators.OperatorOnBackpressureBuffer$BufferSubscriber.complete(OperatorOnBackpressureBuffer.java:163)
at rx.internal.util.BackpressureDrainManager.drain(BackpressureDrainManager.java:187)
at rx.internal.util.BackpressureDrainManager.terminateAndDrain(BackpressureDrainManager.java:115)
at rx.internal.operators.OperatorOnBackpressureBuffer$BufferSubscriber.onCompleted(OperatorOnBackpressureBuffer.java:134)
at rx.subjects.SubjectSubscriptionManager$SubjectObserver.onCompleted(SubjectSubscriptionManager.java:231)
at rx.subjects.AsyncSubject.onCompleted(AsyncSubject.java:101)
at com.couchbase.client.core.endpoint.query.parser.YasjlQueryResponseParser.finishParsingAndReset(YasjlQueryResponseParser.java:358)
at com.couchbase.client.core.endpoint.query.QueryHandlerV2.decodeResponse(QueryHandlerV2.java:176)
at com.couchbase.client.core.endpoint.query.QueryHandlerV2.decodeResponse(QueryHandlerV2.java:61)
at com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:287)
at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81)
at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
at com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
at com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
at com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
at com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
at com.couchbase.client.deps.io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
at com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1302)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
at com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at com.couchbase.client.deps.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:135)
at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:646)
at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:581)
at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:498)
at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
at com.couchbase.client.deps.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:811)
In my test environment with a copy of the production data from a couple of months ago I donāt have this error.
The error only occurs when I run a function that process many documents (65000+). If I run the same query from the web admin interface it returns the data without any error.
I have tried to search for this error - but have not found any explanations or solutions.
This is my environment: Couchbase Server: Community Edition 6.6.0 build 7909 Java SDK: couchbase-java-client-2.5.7.jar Java version: 1.8
Hi @jda
Java SDK 2.5.7 is very old at this point (April 2018), can you try upgrading to 2.7.19? I donāt believe this is a known issue, but always good to be running with the latest and greatest.
And speaking of that, are you considering a move to SDK 3.X, which has been GA for over a year now? SDK 3.x uses a different parsing method than the āYasjlā one used in SDK 2.X, so if this is an issue in the parser, it certainly wonāt exist in 3.x.
Itās a good point. I had to downgrade to 2.5.x at some point due to issues with āSnappy flagā on Community Server - and have left it there since. I could try out the latest version 2.7.x to see if it behaves Ok - and fixes this issue.
I have not had the chance to look at the version 3.x SDK and how many changes it would require to upgrade to using that. I would normally want to run with the most up-to-date version to get the latest fixes and performance improvements.
The change to 3.x is not too huge and highly recommended, we have documentation with full details. (Donāt be put off by the length of it - itās covering all services, you likely wonāt need all of it). The 3.x interface is cleaner and clearer, and thereās a number of performance improvements too under the hood.
Iām installing 2.7.19 now in our dev & test environments. If that works Iāll put it on the production server.
⦠and then it seems Iāll need to have a look at the v.3.x SDK again. Iām not going to use collections nor scopes now - but again would like to be on the latest version. There is just some work in doing this and making sure that the code also works with the new SDKā¦
The code doesnāt fail with the error in production any more!
However, it did time out (when generating and exporting som data)⦠I donāt have anything fact based - but my feeling is that it seems slower after upgrading to 2.7.19⦠I wonder if there are some upgrade/tuning steps that I missed by jumping from 2.5.7 directly to this version
can you quantify āslowerā? Type of operation / latency / throughput etc ā also can you show us your current configuration? It is hard to give generic advice
But there are a number of situations I find difficult to migrate:
In rare situations I have to read some data that Iāve just written (e.g. when creating a user object). In SDK 2 I used N1qlParams.build().consistency(ScanConsistency.STATEMENT_PLUS); added it to the query (and reset it after first call). How should I do this in SDK3?
I use JsonDocument in many places setting data on doc.contents(). Now I use a JsonObject instead - but how can I check if a document is ānewā (used the doc.cas() before).
I know this is a little out of the original scope. But this is where I struggle at the moment trying to get to the newest versionā¦
Also note that you donāt have to build up the connection string with the timeout, you can still use the builder on the environment and set it on the TimeoutConfig.
Yes, but if I use the connection string then the client will handle close of connection on itās own - otherwise I would have to do that (which is really not possible in the application - itās a web site)
that is a bit ambiguous, the cas value itself does not indicate if something is new or not. If you perform a insert operation youāll get an exception if the document already exists - that is the āproperā way to find out ⦠unless Iām missing something in the overall workflow of your app
Leaving aside the doc.cas() == 0 check, which confuses me a bit also - you still get the CAS, itās just separate from the JsonDocument now. collection::get returns a GetResult that has a .cas() method, and same goes for most read and write operations. To make it easier to reuse existing code you could perhaps pass around the GetResult rather than the JsonDocument?