Need Help with error


When using the Dispatcher code found here I am getting this error

{“WorkItem EventStore.ClientAPI.ClientOperations.ReadAllEventsForwardOperation: Position: EventStore.ClientAPI.Position, MaxCount: 500, ResolveLinkTos: False, CorrelationId: 655f5f01-94b8-47f0-834d-1903b6988c7c, attempt: 0, seqNo: 80 never got response from serverLast state update : 3/8/2013 12:03:35 AM, last reconnect : 3/8/2013 12:03:04 AM, now(utc) : 3/8/2013 12:03:43 AM.”}

The error is pretty self explanatory, but I am not sure why it would happen every single time. Before I do a bunch of digging, is there anything obvious that would make this error happen?



I am still able to run that code against a 1.0 version of GetEventStore with no problems. I haven’t had time to try it with the 1.0.1 version yet. Can you let me know what version you are running?


Just thought of something else. How are you setting up your EventStoreConnection?

Here is a snippet of how I run my console client

private static readonly IPEndPoint LocalTcpEndPoint = new IPEndPoint(IPAddress.Loopback, 1113);

static void Main(string[] args)


var conn = EventStoreConnection.Create();

var esRepos = new GetEventStoreRepository(conn, LocalTcpEndPoint);

//do stuff here


The port is key. Make sure you aren’t using 2113 which is the http port.

Sorry for spamming, but here is my Console app for running the dispatcher. Disregard the doc store setup. The last lines are the key pieces of how to start the dispatcher listening.

class Program


private static readonly IPEndPoint LocalTcpEndPoint = new IPEndPoint(IPAddress.Loopback, 1113);

static void Main(string[] args)


var ds = new DocumentStore()


Url = “http://localhost:8081”,

DefaultDatabase = “Portfolio”


var memEvtBus = new MemoryEventBus();

memEvtBus.Register(new MyEventHandlers(ds));

var store = EventStoreConnection.Create();

var listener = new GetEventStoreEventDispatcher(store, LocalTcpEndPoint, memEvtBus);






Hi Phil,

I’m running it against 1.0.1. It was working flawlessly on my local machine and when I went to run it on my staging server, I started seeing the errors. After that it started happening on my local machine too.

Your setup looks similar to mine (I also verified I am running on the tcp port) so I will have to look into this further in the morning and get back to you. Thanks for your help.


You can try using ClientAPI v.1.1.0-rc1. It is revamped version of ClientAPI which is less prone to race conditions inside connection logic. It also provides more ways to know what’s happening with your connection.
When you create connection, you can specify callbacks for five events: OnClosed (when EventStoreConnection is completely closed because something very bad happened or reconnection limit is reached), OnErrorOccurred (some connection-wide error occured, should be very rare, if any), OnConnected (TCP connection to EventStore is established), OnDisconnected (TCP connection was closed), OnReconnecting (next try for reconnection is being attempted).

Please look at arguments they accept, some of them have Exception or string (reason) as parameters, that can give you a clue on what is happening.

Other possibility is that your EventStore is up, but still initializing, when you send read request. In that case the request will be ignored on server and you won’t ever receive any response. That is handled better in dev version of EventStore and handled appropriately in 1.1.0-rc1 version of ClientAPI, but if you are using <= 1.0.1 of EventStore – you should somehow make sure that EventStore is ready (is in working state) when you send requests.

When you are using EventStore in embedded mode (as it was discussed in few threads earlier) you won’t have this problems, because when you start node, you wait for BecomeMaster message on EventStore’s internal message bus, which ensures that node is up, initialized and ready to serve requests.

Hope that helps you.


I’ll try the 1.1.0-rc1 client api. Where can I get it?


It’s up on nuget

Blah, I checked but didn’t put in the prerelease option.

Thanks :slight_smile:

Seems the solution was that I needed to set the OperationTimeout to be bigger. New details on the ClientApi logging helped out a lot.

Thanks everyone for the help.