PlanningFailureException when Flux returned from repository to Mono<ServerResponse>

Java SDK
1

Hi All,
I am using spring data couchbase 4.05 with spring web flux 5.2.10 along with couchbase 7 beta server.
I am getting PlanningFailureException when Flux is returned from end point.No error when Mono is returned.

My Router is as below

.andRoute(RequestPredicates.GET("/project")
.and(RequestPredicates.accept(MediaType.APPLICATION_JSON)), handler::findAll)

My handler is

public Mono findAll(ServerRequest request){
return ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).body(BodyInserters.fromPublisher(projectRepository.findAll(),Project.class));
}

Can somebody tell me why PlanningFailureException is returned when Flux is returned from repository?

Thanks,
Isuru

Error Trace

om.couchbase.client.core.error.PlanningFailureException: The server failed planning the query
** at com.couchbase.client.core.io.netty.query.QueryChunkResponseParser.errorsToThrowable(QueryChunkResponseParser.java:136) ~[core-io-2.0.10.jar:na]**
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Error has been observed at the following site(s):
|_ checkpoint ⇢ HTTP GET “/project” [ExceptionHandlingWebHandler]
Stack trace:
at com.couchbase.client.core.io.netty.query.QueryChunkResponseParser.errorsToThrowable(QueryChunkResponseParser.java:136) ~[core-io-2.0.10.jar:na]
at java.base/java.util.Optional.map(Optional.java:265) ~[na:na]
at com.couchbase.client.core.io.netty.query.QueryChunkResponseParser.error(QueryChunkResponseParser.java:117) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.io.netty.chunk.ChunkedMessageHandler.lambda$maybeCompleteResponseWithFailure$1(ChunkedMessageHandler.java:260) ~[core-io-2.0.10.jar:na]
at java.base/java.util.Optional.orElseGet(Optional.java:369) ~[na:na]
at com.couchbase.client.core.io.netty.chunk.ChunkedMessageHandler.maybeCompleteResponseWithFailure(ChunkedMessageHandler.java:259) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.io.netty.chunk.ChunkedMessageHandler.channelRead(ChunkedMessageHandler.java:191) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[core-io-2.0.10.jar:na]
at com.couchbase.client.core.deps.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[core-io-2.0.10.jar:na]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

1 Like
2

@deniswsrosa @mreiche @AV25242

I checked this with couchbase 6.6 and 6.5 as well.I get the same error.

Please let know if it is a flow in the couchbase spring data 4.05?

Thanks,
Isuru

1 Like
3

@iisuru our team will look into this and see what they can find.

1 Like
4

@AV25242
Thanks for the prompt response and do not hesitate to contact me if further configuration settings are needed for tracing the issue.

1 Like
5

A good place to start would be to eliminate all the reactive framework and the non spring-data code. Is there an override for projectRepository.findAll()? From a non-reactive repository, what does the call “projectRepository.findAll()” return?

1 Like
6

@mreiche
non reactive case it returns Iterable.Reactive case returns Flux.I tested non reactive scenario also.It is also throwing a different nio related exception with Tomcat default springboot.

1 Like
7

Like I said, isolate the spring-data personRepository.findAll() from all your other code.
If personRepository().findAll() works from a non-reactive PersonRepository, it should work from a reactive PersonRepository - it is the same call.

	public List<T> all() {
		return reactiveSupport.all().collectList().block();
	}
8

@mreiche
With SpringData Couchbase 4.o.3 with SpringBooot and Tomcat with nonreactive mode

I can execute findById without error.

With Iterable findAll I am stil lgetting planning failure exception with below suppressed exception.

Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99) ~[reactor-core-3.3.9.RELEASE.jar:3.3.9.RELEASE]
at reactor.core.publisher.Mono.block(Mono.java:1680) ~[reactor-core-3.3.9.RELEASE.jar:3.3.9.RELEASE]
at org.springframework.data.couchbase.core.ExecutableFindByQueryOperationSupport$ExecutableFindByQuerySupport.all(ExecutableFindByQueryOperationSupport.java:70) ~[spring-data-couchbase-4.0.3.RELEASE.jar:4.0.3.RELEASE]
at org.springframework.data.couchbase.repository.support.SimpleCouchbaseRepository.findAll(SimpleCouchbaseRepository.java:173) ~[spring-data-couchbase-4.0.3.RELEASE.jar:4.0.3.RELEASE]

9

Provide your PersonRepository, Person and configuration classes.

10

interface EmployeeRepository extends CouchbaseRepository<Employee, String>{
}

@Document
public class Employee {
@Id
private String id;
@Field
private String name;
//get set
}

@Configuration
@EnableCouchbaseRepositories(basePackages = { “com.example.couchbase65.dao” })
public class CouchbaseConfig extends AbstractCouchbaseConfiguration {

@mreiche Let me know if you need any more configs

11

Please provide the complete files. You can xxx out things like the host connection address.

12

@mreiche

Here is the source code https://github.com/isuru-sam/couchbase6.5
I doubt its connection string since I can properly insert and query by id also connectivity is for localhost so no security breach to xxx out.
Since multi buckets are enabled you need to create account and employee buckets if running locally.

Thanks
Isuru

13

There is no Person or Project classes in that code. There is nothing that uses Flux in that code.
If you would like assistance, please be very accurate and specific in providing a reproducer and describing how to reproduce the issue. (i.e. what url to use to insert documents, what url to use to find documents)

14

@mreiche
I switched to non reactive code and shared with you the same since you asked me to check it in non reactive mode in spring boot.The github url i sent you reflects non reactive springboot case with coucbase6.5 or 6.6 or 7 saving Employee objects.
Cocuhabase is setup locally as below.

Thanks,
Isuru

15

@mreiche

I just need to get the verification on findAll is working in new springdata4.05 with couchbase 6.5,6.6 upwards by any means.If you can confirm this I can still troubleshoot in my code.

16

findAll() is used in multiple places in the integration tests in spring-data-couchbase. It works fine. (modify integration.properties to use “unmanaged” to use your own cb server)
In your app, I used employee/saveEmp to save an employee and employee/all to fetch that employee. It works fine.

17

Ok then it might be my fault.I will investigate further.

Thanks for the support @mreiche

18

The reason you get a Planning exception is because you don’t have a primary index.
It’s discussed in your other thread.

  • indexes are not needed for findById(), [they are needed for any other find]
19

But primary indexes are not encouraged.So a id based secondary GSI would be the most appropriate in this situation.And the error message seems misleading that error trace and message won’t specify about missing index.It would have been nice to have informative message.

20

So a id based secondary GSI would be the most appropriate

Not quite. As stated in the other thread, findById uses the kv api which doesn’t need an index. ( this is why your findById (that returned a Mono) always worked). Any other find - including findAll() requires an index. The predicate _class = ‘packagename.classname’ is added to those finds, so a GSI on _class would be appropriate.

It would have been nice to have informative message.

I’ve opened a bug for that. no details in exception when executing find query when no index exists [DATACOUCH-656] · Issue #964 · spring-projects/spring-data-couchbase · GitHub. The complete message is displayed if when the query is executed in the Query tab of the couchbase console:

select * from employee where _class = “com.example.couchbase65.dao.Employee”
{
“code”: 4000,
“msg”: “No index available on keyspace default:employee that matches your query. Use CREATE PRIMARY INDEX ON default:employee to create a primary index, or check that your expected index is online.”,
“query”: “select * from employee where _class = "com.example.couchbase65.dao.Employee"”
}