Problem with C# Client Api 3.4 - liveProcessingStarted called before being live

We are having some issues with the eventstore C# client api.

The method used to connect the client api is connection.SubscribeToStreamFrom and we want to react when the subscription has gone live, so registers a method on liveProcessingStarted.

We are experiencing that the liveProcessing started is called prematurely and thus messes up our logic. It is called before any events is even processed.

It seems as if the connection is re-established afterwards and the events are then processed, at a later point liveProcessing is then correctly called.

The stream being subscribed to is a category projection

We are running Eventstore 3.4 on a windows server and uses version 3.4 of the .net client api

We are using the following connections settings:

KeepReconnecting();

KeepRetrying();

FailOnNoServerResponse();

In the eventstore log we can see the following entries

[PID:06448:028 2016.05.02 13:42:44.106 INFO TcpService ] External TCP connection accepted: [Normal, 192.168.10.95:56446, L192.168.5.122:1113, {313ce737-b332-4ebe-abe6-9c780ff11504}].

[PID:06448:028 2016.05.02 13:42:45.069 INFO TcpService ] External TCP connection accepted: [Normal, 192.168.10.95:56452, L192.168.5.122:1113, {08843aee-57a0-4418-9e9d-a73ca6a7651b}].

[PID:06448:027 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.470: N192.168.10.95:56446, L192.168.5.122:1113, {313ce737-b332-4ebe-abe6-9c780ff11504}]:Received bytes: 15824, Sent bytes: 30646048

[PID:06448:027 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56446, L192.168.5.122:1113, {313ce737-b332-4ebe-abe6-9c780ff11504}]:Send calls: 312, callbacks: 312

[PID:06448:019 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56452, L192.168.5.122:1113, {08843aee-57a0-4418-9e9d-a73ca6a7651b}]:Received bytes: 3975, Sent bytes: 3960

[PID:06448:027 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56446, L192.168.5.122:1113, {313ce737-b332-4ebe-abe6-9c780ff11504}]:Receive calls: 297, callbacks: 297

[PID:06448:019 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56452, L192.168.5.122:1113, {08843aee-57a0-4418-9e9d-a73ca6a7651b}]:Send calls: 180, callbacks: 180

[PID:06448:027 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56446, L192.168.5.122:1113, {313ce737-b332-4ebe-abe6-9c780ff11504}]:Close reason: [ConnectionReset] Socket receive error

[PID:06448:019 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56452, L192.168.5.122:1113, {08843aee-57a0-4418-9e9d-a73ca6a7651b}]:Receive calls: 181, callbacks: 181

[PID:06448:019 2016.05.02 13:51:42.470 INFO TcpConnection ] ES TcpConnection closed [13:51:42.471: N192.168.10.95:56452, L192.168.5.122:1113, {08843aee-57a0-4418-9e9d-a73ca6a7651b}]:Close reason: [ConnectionReset] Socket receive error

[PID:06448:027 2016.05.02 13:51:42.470 INFO TcpConnectionManager] Connection ‘external-normal’ [192.168.10.95:56446, {313ce737-b332-4ebe-abe6-9c780ff11504}] closed: ConnectionReset.

[PID:06448:019 2016.05.02 13:51:42.470 INFO TcpConnectionManager] Connection ‘external-normal’ [192.168.10.95:56452, {08843aee-57a0-4418-9e9d-a73ca6a7651b}] closed: ConnectionReset.

[PID:06448:006 2016.05.02 13:51:42.470 DEBUG PersistentSubscripti] Lost connection from 192.168.10.95:56446

[PID:06448:006 2016.05.02 13:51:42.470 DEBUG PersistentSubscripti] Lost connection from 192.168.10.95:56452

192.168.10.95 being the client maching and 192.168.5.122 the event store server

What does a verbose log from client say?

Thank you for the quick reply.

I actually found the issue in the verbose logging

We use IObservable.ObserveOn to marshall the event handling to the UI thread. But this is apparently done by simply scheduling the handling not actually doing it.

As the liveProcessingStarted is called on a worker pool thread it skips the long queue.

Marshalling the liveProcessingStarted to the same thread as the handling seemed to do the job