By default, JSONProcessor transactions (for example, JSON and JSONv2) are processed by the default semaphore pool. The default semaphore pool is the pool that is used to handle direct user transactions. If a JSON integration is sufficiently aggressive, it can start fighting for resources with user transactions and cause performance degradation to end users.

Steps to Reproduce

  1. Do a JSON request.
  2. Open Transactions (all user).
  3. Find your transaction and click the record to open it.
  4. In the transaction form, click View Log Entries.
  5. Find the thread that your transaction was processed on.
  6. Notice the thread name starts with Default.


Use a REST-style web service rather than JSON. REST web services do not compete with user traffic by default; however, if you would like to continue using a JSON service you can set up a separate semaphore queue for your requests by doing the following:

  1. In the navigation filter, type sys_semaphore.list.
  2. Click New.
  3. Name the file, for example, JSON.
  4. In the Parameters field, enter JSON, JSONv2.
  5. Click Submit.

To make sure this works, do a JSON call using curl and the Log files to see what type of thread (and therefore what type of semaphore pool) was used. If the thread name starts with Default, then it did not work. As an alternative to going through the Log files, if you have a sufficiently slow request, you can fire the request, then quickly run Your new JSON semaphore queue shows up as one of the available pools in If the  workaround was done correctly, your request shows up as occupying one of the threads in your new queue.

curl -u admin:admin -o "JSONoutput.txt" ""


Related Problem: PRB631545

Seen In

Eureka Patch 4
Eureka Patch 7 Hot Fix 12
Geneva Patch 5

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-12-07 09:59:32