[
Date Prev][
Date Next][
Thread Prev][Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] Should the Concurrency specification introduce a way for applications to access named semaphores in a Jakarta EE application?
|
On 2/27/25 1:09 PM, Nathan Rauh wrote:
Scott,
For
non-clustered deployments, the concurrency specification
already has maxAsync on ManagedExecutorDefinition.
@ManagedExecutorDefinition(name
= “java:app/concurrent/max5executor”, maxAsync = 5)
This gives
you a [Managed]ExecutorService to which you can submit
tasks. No more than 5 tasks will be allowed to run at a
time. This sounds like it would cover what you are asking
for in the case of single server.
Agreed and thanks for pointing out that ManagedExecutorDefinition `maxAsync`
can be used already for the non-clustered case and is already
integrated in EE!
The
Concurrency specification doesn’t currently have anything
that covers coordination across a cluster, which isn’t to
say it couldn’t be added. The topic of clustered deployments
seems to be largely absent from Jakarta EE in general, which
probably needs to be addressed before Concurrency can start
to define things in that area. If it were, another aspect
of Concurrency that could benefit from it would be
coordinating the execution of a scheduled asynchronous
method across a cluster to only run on one member rather
than running on all members at the scheduled times.
That would be a nice enhancement
although for simply ensuring that cluster nodes do not get
overloaded, using the existing ManagedExecutorDefinition support can
ensure that nodes do not thrash which can lead to cluster nodes
leaving the network. In the past, I was able to use (local node
only) named semaphores to maintain the cluster health that met a
certain SLA.
Scott
In the past, I
have seen named semaphores as a way to ensure that
an EE application can meet expected service level
agreements (for both clustered + non-clustered
deployments). Would the
Concurrency Specification be the right place to
introduce
In the past, I have seen named semaphores as a way
to ensure that an EE application can meet expected
service level agreements (for both clustered +
non-clustered deployments). Would the Concurrency
Specification be the right place to introduce named
semaphores?
A high level example would be something like:
Configure a set of named semaphores in an
application that are associated with certain EE
container threads. Each defined semaphore would
have a name and a number of permits.
As part of the app design/development process,
identify application operations that are CPU
expensive so that a smaller number of permits would
be used. Think of an administrative UI operation
that has to access all rows in a database table that
could be fast for a small number of rows but very
expensive for a large number of rows. Perhaps the
number of permits would be really low like 1-5 to
throttle the number of administrators that could
access that very expensive part of the application
at the same time. For less expensive operations,
the number of permits could be much higher.
Additional changes would be needed to be scoped out
to make use of named semaphores in various EE
containers that could benefit from them.
An alternative could be to introduce named
semaphores at the Java SE level via the
java.util.concurrent.Semaphore class which could
also be made use of by various EE containers.
Suggestions?
Thanks,
Scott
