Configuring Semaphore Permits Dynamically

[Tom Parkinson]

Hello

I have a problem where the use of hazelcast semaphores would be ideal however i need to be able to create semaphores dynamically with varying numbers of permits.

I know I can create named semaphores in the hazelcast configuration xml using regular expressions so i could say:

<semaphore name="PERMITS.10.*">

<initial-permits>10</initial-permits>

</semaphore>
<semaphore name="PERMITS.20.*">

<initial-permits>20</initial-permits>

</semaphore>

Then i could create a new semaphore called PERMITS.10.Something and it would have 10 permits.

The problem with this is I would need to define a profile for every number under the sun. I would simply like to say give me a new semaphore with N permits.

Is there a solution for this?

Thank You

Tom 

[Ryan Thomas]

Hi Tom,

We ran into this very issue in one of the services we build.

The issue was that if we did not configure the semaphore in the hazelcast.xml, when we fetched one by name it would *sometimes* return a "random" amount of permits... We found that adding a "default" named semaphore helped produce a more stable result (we needed 20 in this case, but it was dynamically configurable our app) here is the xml:

    <semaphore name="default">
        <initial-permits>20</initial-permits>
        <semaphore-factory enabled="false">
        </semaphore-factory>
    </semaphore>

We've abstracted all cluster functionality away behind a ClusterManager interface, we have this method on it:

@Override public ClusterSemaphore createSemaphoreIfAbsent(@NotNull final String name, final int permits)

A ClusterSemaphore is just a delegate to the actual Semaphore impl for the cluster. In this method we do something funky - this is where it gets terrible...

All of this is done in a critical section btw, so there is no chance of the semaphore being acquired or released when we create it.

                        /**
                         * The hazelcast semaphore gets its initial value from the hazelcast.xml configuration. We cannot change this at runtime so in order to
                         * get semaphores that are of a differing size, we need to either reduce the number of permits or increase them by releasing them. This
                         * is all done in this critical section, however it is possible to access the semaphore during this time by manually fetching it from
                         * the hazelcast instance - DO NOT DO THIS - all semaphore creations and gets should be done vis this method or
                         * {@link #getSemaphore(String)}.
                         */
                        ISemaphore semaphore = hc.getSemaphore(name);
                        if (semaphore.availablePermits() > permits) {
                            semaphore.reducePermits(semaphore.availablePermits() - permits);
                        }
                        else if (semaphore.availablePermits() < permits) {
                            semaphore.releaseDetach(permits - semaphore.availablePermits());
                        }

Hope that helps, we have been running this in production for nearly a year now with no issues, we have a descent amount of monitoring around the permits on the semaphores and have not seen any abnormalities. We are on Hazelcast 2.1

Cheers,

ryan

Tom 

-- 
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tom Parkinson]

Thank You very much for that Ryan I shall experiment with that today!

Tom