Morgan F.

So I am in favour of using the system store in general because in most cases [outside of dev] if you're relying on requests or a similar library you're going...

@glyph I think you may have hit the nail on the head there. That is a significant reason (and addresses the other issues outlined) to use a more centralized location...

We could easily pull the oslo.cache (well, similar) code into the dogpile.cache repository to optionally be layered in when debugging. We had issues that could only be solved by tracking...

As an additional point, there would still be a git replica in github but it would be under the OpenStack organization (https://github.com/openstack/python-memcached or similar). The changes would be: - review.openstack.org...

I'll start the process of getting the bits in place for moving this to the openstack infrastructure. I'll propose a PR here once that is ready to link to the...

Revisiting this conversation. I know it dropped off the radar (some emails I think were lost - and I got a bit swamped, now revisiting directly). Sean, are you willing...

I work with @nickstenning and wanted to provide additional context to this bug: It looks like this is the same bug at #670 Doing a bit of debugging it appears...

Reproduction steps include adding load to nchan with the rough config Nick provided and then request a non-existent channel with an invalid id in 'Last-Event-ID' header. I found it was...

@b-n I found that it didn't require a message on the queue for the requested channel (in fact I think if the channel has a message there isn't a crash)....

I can confirm it can be never used/never existing, my local repro steps used both expired and never existing.