Latest commit breaks reuse of kinesalite object

[mhart]

Latest commit breaks reuse of kinesalite object

[mhart]

Bizarre error! But have reproduced no problem, thanks.

I'll look into it!

[mhart]

Oh right – I see, it's because you're trying to reuse the same kinesalite instance.

If you change this so that you create a new kinesalite instance each time it should work fine.

I'm not entirely sure that trying to reuse an instance once it's been closed should be a supported feature – it would mean hacking into the listen method and re-initializing the levelup database, etc – and listen isn't really a synonym for open so I don't think this is semantically correct.

I'll definitely make the error reporting a little nicer though.

[rclark]

Yeah the use-case is slightly odd, but common if you're using kinesalite in tests and you want to start fresh between individual tests.

I've been running tests like this with dynalite for some time, reusing the same instance. Is there a difference there?

[mhart]

@rclark there isn't a difference as of architect/dynalite#30

The problem is that close really should close everything, including the database – this is especially important when using an on-disk leveldb instance. To re-open the database, you need to create a new instance.

[mhart]

Didn't realise that a patch release would break this use case, so sorry about that! Problem is it's exploiting a bug that existed in the first place 😸

[rclark]

Problem is it's exploiting a bug that existed in the first place

Totally fair. I guess it wouldn't be possible to detect and explicitly fail on reuse unless you hijack the listen method?

[mhart]

Yep, that's what I'm doing 👍

[mhart]

Going with Instance has been closed, please create a new instance to listen again – sound ok?

[mhart]

Now that I'm looking at patching listen... I mean... I'm considering just recreating the store... 😈

I'll give it a quick test, and if it works maybe I'll just do it... If there are issues down the track with it, then can look at throwing an error instead.

[mhart]

Ok – so the only issue I've run into is with the 0 millisecond timeouts you're using on your create stream calls, etc.

Basically, I use setTimeout no matter what – so even with a 0 millisecond timeout, it can try to read/write after the database has closed.

I'm considering that a separate issue which I might try to patch

[mhart]

Ok, so I relented 😸 – you should be able to keep using it as-is. Hopefully I haven't opened a can of worms! Don't really think so though...

[mhart]

Released as v1.4.3

[mhart]

Also fixed in dynalite, released as v0.11.3 – thanks for the report!