Singleton style consumer on EventBus

[Konstantyn Smirnov]

Lets say I have an event-bus consumer which is doing heavy lifting or has an exclusive access to an external resource and I want it to be a singleton across the whole event-bus.

Is it possible to restrict consumer registration across the cluster to a single instance?
Are there means to support it automatically?

[Jochen Mader]

The event-bus explicitly allows registering multiple consumers to the same address.

There is also no notion of a master that could prevent such things.

 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/e619d1a4-c19e-4fc7-9b6f-f54f1ae5c704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Principal IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Konstantyn Smirnov]

Any idea on how this can still be implemented?

Btw, can I check if the address already registered on EB without checking __vertx.subs?

[Clement Escoffier]

Hi,

you can try with a distributed lock with a very long timeout. If you acquire the lock, you are the master. If you crashes, the lock is released and another one if going to acquire it. Notice that, in the case of split-brain, things can be go south ;-).

Clement

On 7 Dec 2017, at 10:27, Konstantyn Smirnov <inje...@gmail.com> wrote:

Any idea on how this can still be implemented?

Btw, can I check if the address already registered on EB without checking __vertx.subs?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1861f33d-730c-4dde-8b61-245d0bdefcd2%40googlegroups.com.

[Konstantyn Smirnov]

How about performance impact?

If I acquired 1 mio locks already, how would the latency across the cluster for acquiring new locks grow?

Konstantyn

[Konstantyn Smirnov]

Is the cluster-wide lock is locked against a thread?

I acquired a lock in send-worker-2, and in vert.x-eventloop-thread-3 it's not cannot be acquired anymore...

On Thursday, December 7, 2017 at 10:33:22 AM UTC+1, clement escoffier wrote:

[Thomas SEGISMONT]

Locks are not per thread. We call them locks but their behavior is more of a semaphore with a single permit. You can only acquire it once cluster wide, and any thread (from the node which acquired the lock) can release it.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6b0cbefb-1589-4c3d-9e3c-fc6473d4834e%40googlegroups.com.

[Konstantyn Smirnov]

Ah thanks.

Another question: can I check for lock existence somehow? Or is it only possible through acquiring the lock? Shall I look through __vertx.semaphore (or alike) cluster-wide map?

On Friday, December 15, 2017 at 10:56:59 AM UTC+1, Thomas Segismont wrote:

Locks are not per thread. We call them locks but their behavior is more of a semaphore with a single permit. You can only acquire it once cluster wide, and any thread (from the node which acquired the lock) can release it.

2017-12-14 16:05 GMT+01:00 Konstantyn Smirnov <inje...@gmail.com>:

Is the cluster-wide lock is locked against a thread?

I acquired a lock in send-worker-2, and in vert.x-eventloop-thread-3 it's not cannot be acquired anymore...

On Thursday, December 7, 2017 at 10:33:22 AM UTC+1, clement escoffier wrote:

Hi,

you can try with a distributed lock with a very long timeout. If you acquire the lock, you are the master. If you crashes, the lock is released and another one if going to acquire it. Notice that, in the case of split-brain, things can be go south ;-).

Clement

On 7 Dec 2017, at 10:27, Konstantyn Smirnov <inje...@gmail.com> wrote:

Any idea on how this can still be implemented?

Btw, can I check if the address already registered on EB without checking __vertx.subs?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1861f33d-730c-4dde-8b61-245d0bdefcd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

[Thomas SEGISMONT]

On an HazelcastInstance, you can call com.hazelcast.core.HazelcastInstance#getLock with the name "__vertx.my-lock-name"

On the resulting ILock, use com.hazelcast.core.ILock#isLocked

That's the only thing possible I can think about.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/3dd7d51e-146a-4ec2-817f-24845c7f0e2f%40googlegroups.com.