Open dosomder opened 1 year ago
Hey @dosomder,
Can you share some info on your runtime workload when it happens? Is there a situation where you delete a stream while another part of your code is reading from it?
We don't delete a stream in particular but we set maxAge and maxCount.
In this case when the exception happens, we try to read the last event from a stream and expect it to be empty. This is how we read the stream. We handle the StreamNotFoundException in the rxjava chain.
Observable.fromPublisher(
this.client.readStreamReactive(
this.getStreamName(),
ReadStreamOptions.get().fromEnd().backwards().maxCount(1)))
// Only interested in the actual event
.filter(ReadMessage::hasEvent)
.map(ReadMessage::getEvent)
// Decode event
.mapOptional(this.translator::decodeEvent)
// A none existing stream is to be treated as if no events exist
.onErrorComplete(StreamNotFoundException.class::isInstance);
@dosomder Sorry for taking time to respond. I think you have diagnosed the issue properly. I need to conduct some tests to see when an exception has been raised in a future, was it already processed by the observer of the subscription or if it's the other way around.
@YoEight Meanwhile we are on client 5.x and since then (6 weeks now) we have not seen this exception on our environments.
Unfortunately, I can assure you that the issue is still there, even if it's scarce. I never managed to reproduce it locally but per RX documentation, the way we just the library in this context is wrong.
We rarely observe the following exception on our servers which crashes the application:
From the stacktrace it looks like the StreamNotFoundException (or at least onError) is emitted twice which is not legal for a Publisher. The first time may be here: https://github.com/EventStore/EventStoreDB-Client-Java/blob/trunk/db-client-java/src/main/java/com/eventstore/dbclient/AbstractRead.java#L108 and the second time here: https://github.com/EventStore/EventStoreDB-Client-Java/blob/trunk/db-client-java/src/main/java/com/eventstore/dbclient/AbstractRead.java#L113 (this line is in the stacktrace).
Although the ReadSubscription tries to protect against this with an AtomicBoolean so I don't know how this exception can still happen. There was some exception handling changes here, not sure if they are related: https://github.com/EventStore/EventStoreDB-Client-Java/commit/3fb47014ce22d4cfae2ad209ccde08d393f64126
Client: 4.3.0