|Summary:||using semaphores in jmeter (block critical regions)|
|Component:||Main||Assignee:||JMeter issues mailing list <issues>|
|Severity:||enhancement||CC:||epikhinm, jmeter, p.mouawad|
Description Christoph 2007-09-13 06:27:26 UTC
hi, in our testplans, we needed a sort of "semaphore" mechanism, e.g.: - we have problems if more than 10 parallel logins to our webapp exists - we have a lot of threads that create, rename and delete channels. one thread can delete a channel that another thread tries to rename. these are only 2 examples, but since we implemented this controller, we use it very often. for this improvement, JMeterUtils.java has methods for acquiring and releasing semaphores. StandardJMeterEngine.java was patched to clear all semaphores when starting a test (if someone stops the test and there exists a sempaphore that was not released). Moreover, JMeterThread.java was patched, that all semaphores in a threadgroup are released if the scheduler stops the test (before releasing the semaphore with a sampler). acquiring and releasing a semaphore can be either done by calling the 2 methods acquireSemaphore and releaseSemaphore, or by using the 2 samplers that come with the patch (Java Request). If you are interested in this Feature, i would implement a SemaphoreSampler with a nice GUI :) The sampler works like this: With the "AcquireSemaphore" sampler, you can define the begin of the critical region by calling the acquireSemaphore-function. It acquires the given number of permits (count-parameter) from this semaphore, blocking until all are available. When leaving the critical region, use the ReleaseSemaphore sampler with the unique semaphore name as parameter. setting the "count" parameter to "1" would cause this sampler to work like a "mutex". Semaphores are supported since Java 1.5, so the build script has to be updated to build JMeter with Java Version 1.5. greets, chris
Comment 2 Sebb 2007-09-13 07:58:23 UTC
JMeter currently requires a minimum of Java 1.4. We don't have plans to require Java 1.5 at present. However the functionality would be useful. I believe there is a library containing semaphores which runs on 1.4. Provided that the license is compatible, we could use that.
Comment 4 Sebb 2009-05-08 17:54:39 UTC
*** Bug 36227 has been marked as a duplicate of this bug. ***
Comment 5 Sebb 2012-01-09 16:38:20 UTC
(In reply to comment #0) > hi, > > in our testplans, we needed a sort of "semaphore" mechanism, e.g.: > - we have problems if more than 10 parallel logins to our webapp exists That's a bug in the web-app ... > - we have a lot of threads that create, rename and delete channels. one thread > can delete a channel that another thread tries to rename. Again that's something that independent users may encounter normally. So I don't think these use cases are typical. AFAICT, in your case, the semaphores are being used to avoid triggering the errors. However, it may still be useful as a way of configuring a test. I'm not sure that a sampler is the correct test element to use; that needs to be given more thought. Would a Timer be better? After all, that's the effect of the semaphore.