ORESoftware/live-mutex

Broker on different instance than Client

eLoyyyyy opened this issue · 6 comments

eLoyyyyy commented

I was trying to create a separate instance for both Broker and the Client. Being that the Broker is in, let say, an EC2 instance. Then the Client is part of a monolith application. Now seeing thru code, it seems that you don't use the host config in the Client constructor to point to the Broker (or I'm just stupid to look at trivial code). Can you point me to the right direction? I keep on having the ECONNREFUSED => 127.0.0.1:6970 even tho I specified in the Client opts the host and the port of the Broker.

Edit:
Here is the line that I'm talking about.

ORESoftware commented

Thanks I will have to make a fix to the code, it's always listening to localhost, I suspect you may wish to try to connect to 0.0.0.0 instead of 127.0.0.1, but right now the code won't let you. Let me fix that will ping you later today when I am done.

Remember this project will probably work for your use-case, but if you really need something failsafe, using a non-distributed lock is risky. If the broker goes down using live-mutex, you're not in good shape (you can automatically start a new one, but whoever was waiting for a lock will timeout). For networked applications you are going to want a proper distributed lock (multiple brokers with failover, etc), zookeeper supposedly provides that, but it's hard to find good info on it. Redis can do it to, although Redis' algorithm is supposedly not bulletproof. This project was really designed for dev-tools and local locking, but it will probably work for your use-case especially if you just want to get something working and make it more robust later.

ORESoftware commented

Give it a go now, try installing this exact version that I just published 0.1.1055, also try using 0.0.0.0 instead of localhost.

  • 👍1
ORESoftware commented

@eLoyyyyy let me know if you tried it, remember to install version
0.1.1055, also try using 0.0.0.0 instead of 127.0.0.1. networking with docker can be tricky so sometimes just try different combinations for the host.

eLoyyyyy commented

Apologies for the late reply. Thanks for the fix, btw. I didn't know the use case for this until you said that its only good for dev-tool (since you mentioned that this beats Redis-based locks). Now, researching for more robust distributed locks for networked applications, I found this. Hopefully I can find something managed for this. Funny enough, database transaction (with a tweak in transaction level) made me not handle locks in resources, for now.

ORESoftware commented

np, distributed locking is a very difficult software challenge so yeah i would be very selective with the library you choose.