Skip to content
This repository has been archived by the owner on Nov 10, 2020. It is now read-only.

Feature Request: consul.io storage back-end. #15

Open
bentwire opened this issue Mar 13, 2015 · 6 comments
Open

Feature Request: consul.io storage back-end. #15

bentwire opened this issue Mar 13, 2015 · 6 comments

Comments

@bentwire
Copy link

I think consul.io would possibly make a good storage back-end to add to the current in mem back-end.

Thoughts?

@bentwire
Copy link
Author

I'm thinking about doing a first pass at something like this, but I've never written a line of go in my life. ;)

@zhenjl
Copy link
Contributor

zhenjl commented Mar 13, 2015

My main concern for Consul, or something similar like etcd, is performance. They are built for service discovery and not really for high performance messaging.

What's your main goal for using consul? Is it for persistence?

@bentwire
Copy link
Author

Yes just for persistence. Everything would be cached in mem otherwise.

@bentwire
Copy link
Author

Cassandra might be fast enough, especially if some sort of "eventual consistency" is ok between the brokers. I am thinking of a high availability broker here.

@bentwire
Copy link
Author

Oh the other reason for consul is to register surgemq as a service with the system, but that would just be for service discovery.

@ankoh
Copy link

ankoh commented Jan 6, 2016

@bentwire Cassandra is no real option for persistency, really... Same with etcd and consul. Etcd and consul provide distributed data storage for service discovery and Cassandra has been built for totally different use cases.

A persistency solution would more likely go into the direction of LevelDB and requires quite some refactoring work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants