{"action":"created","issue":{"url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/32","repository_url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore","labels_url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/32/labels{/name}","comments_url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/32/comments","events_url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/32/events","html_url":"https://github.com/EventStore/ClientAPI.NetCore/issues/32","id":333073137,"node_id":"MDU6SXNzdWUzMzMwNzMxMzc=","number":32,"title":"Closing an EventStoreConnection causes ObjectDisposedExceptions on re-use","user":{"login":"jimmyheaddon","id":944499,"node_id":"MDQ6VXNlcjk0NDQ5OQ==","avatar_url":"https://avatars1.githubusercontent.com/u/944499?v=4","gravatar_id":"","url":"https://api.github.com/users/jimmyheaddon","html_url":"https://github.com/jimmyheaddon","followers_url":"https://api.github.com/users/jimmyheaddon/followers","following_url":"https://api.github.com/users/jimmyheaddon/following{/other_user}","gists_url":"https://api.github.com/users/jimmyheaddon/gists{/gist_id}","starred_url":"https://api.github.com/users/jimmyheaddon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimmyheaddon/subscriptions","organizations_url":"https://api.github.com/users/jimmyheaddon/orgs","repos_url":"https://api.github.com/users/jimmyheaddon/repos","events_url":"https://api.github.com/users/jimmyheaddon/events{/privacy}","received_events_url":"https://api.github.com/users/jimmyheaddon/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-06-17T16:01:20Z","updated_at":"2018-07-30T15:07:13Z","closed_at":null,"author_association":"NONE","body":"I really don't understand how this library behaves so differently in source, compared to using the NuGet package.  I can replicate this time and time again in production (on different machines), but it just works when I fork the repo and write a unit test :( (it throws an `AggregateException` with an inner `ConnectionClosedException`, which you just don't get in production) with the latest NuGet package and .NET Core 2.0.\r\n\r\nFeel free to delete this if you can't replicate it, I'm at a loss with how to use this library reliably in production :(\r\n\r\n------------\r\nGreetings\r\n\r\nApologies if this has been discussed elsewhere before, I tried searching around for examples to work around this.\r\n\r\nI've found what I believe might be a bug in the API, or at least a usability issue, that I'd like to raise.  When you call `EventStoreNodeConnection.ConnectAsync()` you get a `Task` returned, but the completion of this task doesn't represent the actual connection status.  This leads to race conditions (or even worse, 100% exceptions if Event Store isn't even running) when you try an operation like `ReadStreamEventsForwardAsync()`, only to receive an `ObjectDisposedException`, because the connection hasn't been established.\r\n\r\nCurrently there isn't any way to check if the connection is open, other than subscribing to the event handler, which is messy, because that callback will likely be thrown on a completely different thread to your main thread (it certainly does in my case).\r\n\r\nI started putting together a PR to address this, but this potentially relates to the `IDisposable` implementation in `EventStoreNodeConnection`.  Bear with me...\r\n\r\nThe `IEventStoreConnection` interface inherits from `IDisposable`, but the `EventStoreNodeConnection` implementation doesn't follow the Microsoft guidelines for implementing the disposable pattern.  Therefore, if you call `Close()` on a connection (or it's terminated behind the scenes, e.g. when automatic reconnect is enabled), then you get `ObjectDisposedExceptions` thrown from the API.  This is because `EventStoreConnectionLogicHandler.CloseConnection()` itself disposes of a number of objects, which can't then be re-used until you explicitly call `Connect`, which as I mentioned, isn't always in your control!\r\n\r\n- `EventStoreNodeConnection` would need a private field to maintain whether the instance has been disposed of\r\n- All the public and internal methods of `EventStoreNodeConnection` would need to check the aforementioned flag, before executing\r\n- Ideally the aforementioned private field would be a public property, so that consumers of the API can check whether they need to call reconnect themselves.  It'd be nice to expose this alongside the `Connected` property, to make this much easier to use\r\n\r\n\r\nThoughts?  I'd really like to use this API more reliably, but there's just too much abstracted away from view to really have a fighting chance of orchestrating the various API calls yourself.\r\n\r\nCheers!"},"comment":{"url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/comments/408896746","html_url":"https://github.com/EventStore/ClientAPI.NetCore/issues/32#issuecomment-408896746","issue_url":"https://api.github.com/repos/EventStore/ClientAPI.NetCore/issues/32","id":408896746,"node_id":"MDEyOklzc3VlQ29tbWVudDQwODg5Njc0Ng==","user":{"login":"jimmyheaddon","id":944499,"node_id":"MDQ6VXNlcjk0NDQ5OQ==","avatar_url":"https://avatars1.githubusercontent.com/u/944499?v=4","gravatar_id":"","url":"https://api.github.com/users/jimmyheaddon","html_url":"https://github.com/jimmyheaddon","followers_url":"https://api.github.com/users/jimmyheaddon/followers","following_url":"https://api.github.com/users/jimmyheaddon/following{/other_user}","gists_url":"https://api.github.com/users/jimmyheaddon/gists{/gist_id}","starred_url":"https://api.github.com/users/jimmyheaddon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimmyheaddon/subscriptions","organizations_url":"https://api.github.com/users/jimmyheaddon/orgs","repos_url":"https://api.github.com/users/jimmyheaddon/repos","events_url":"https://api.github.com/users/jimmyheaddon/events{/privacy}","received_events_url":"https://api.github.com/users/jimmyheaddon/received_events","type":"User","site_admin":false},"created_at":"2018-07-30T15:07:13Z","updated_at":"2018-07-30T15:07:13Z","author_association":"NONE","body":"I still see this occasionally, but I can't reproduce it in a simple use case.  The stack trace is just bizarre, and points to it being an internal error with the library, but I just can't replicate it consistently"}}
{"actor":{"display_login":"jimmyheaddon"}}