Administering Concurrent Resources

This chapter provides procedures for administering concurrent resources in the Payara Server environment by using the asadmin command-line utility.

Instructions for accomplishing these tasks by using the Administration Console are contained in the Administration Console online help.

About Concurrent Resources

Concurrent resources are managed objects that provide concurrency capabilities to Jakarta EE applications. In Payara Server, you configure concurrent resources and make them available for use by application components such as servlets and EJBs. Concurrent resources are accessed through JNDI lookup or resource injection.

Concurrent resources are resources of the following types:

Context services
Managed thread factories
Managed executor services
Managed scheduled executor services

For detailed information about concurrent resources, see "Concurrency Specs" in the Jakarta EE specifications.

Default Concurrent Resources

When you create a concurrent resource, you specify a unique JNDI name for the resource. Applications use this name to access the resource.

The Jakarta EE standard specifies that certain default resources be made available to applications, and defines specific JNDI names for these default resources. Payara Server makes these names available through the use of logical JNDI names, which map Jakarta EE standard JNDI names to specific Payara Server resources. For concurrent resources, the mappings are as follows:

java:comp/DefaultContextService: This Jakarta EE standard name is mapped to the concurrent/__defaultContextService resource.
java:comp/DefaultManagedThreadFactory: This Jakarta EE standard name is mapped to the concurrent/__defaultManagedThreadFactory resource.
java:comp/DefaultManagedExecutorService: This Jakarta EE standard name is mapped to the concurrent/__defaultManagedExecutorService resource.
java:comp/DefaultManagedScheduledExecutorService: This Jakarta EE standard name is mapped to the concurrent/__defaultManagedScheduledExecutorService resource.

Configuring Context Services

Context services are used to create dynamic proxy objects that capture the context of a container and enable applications to run within that context at a later time. The context of the container is propagated to the thread executing the task.

Jakarta Concurrency specifies that certain default resources be made available to applications, and defines specific JNDI names for these default resources. Payara Server makes these names available through the use of logical JNDI names, which map Jakarta EE JNDI names to specific Payara Server resources. For context services, the mapping is as follows:
java:comp/DefaultContextService
This Jakarta Concurrency standard name is mapped to the concurrent/__defaultContextService resource

To Create a Context Service

Context services can be created by using Admin Console or Asadmin commands.

To create a new Context Service in the Admin Console, go to Resources → Concurrent Resources → Context Services → New:

New Context Service

Alternatively, you can use the create-context-service asadmin command to create a context service resource.

Because all JNDI names are in the java:comp/env subcontext, when specifying the JNDI name of a context service, use only the concurrent/`name format. For example, `concurrent/Context1.

Creating a context service resource is a dynamic event and typically does not require server restart. Applications can use a resource as soon as it is created. However, if an application tried to use a resource before it was created, and that resource is created later, the application or the server must be restarted. Otherwise, the application will not be able to locate the resource.

Ensure that the server is running. Remote subcommands require a running server.
Create a context service by using the create-context-service subcommand.
If necessary, notify users that the new resource has been created.

Example 14-1 To Create a Context Service

This example creates a context service resource named concurrent/Context1.

asadmin> create-context-service concurrent/Context1
Context service concurrent/Context1 created successfully.
Command create-context-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help create-context-service at the command line.

To List Context Services

Use the list-context-services subcommand in remote mode to list the existing context service resources.

Ensure that the server is running.
Remote subcommands require a running server.
List context service resources by using the list-context-services subcommand.

Example 14-2 To List a Context Service

This example lists context service resources on the default server instance, server.

asadmin> list-context-services
concurrent/__defaultContextService
concurrent/Context1
concurrent/Context2
Command list-context-services executed successfully.

To Update a Context Service

You can change all of the settings for an existing context service resource except its JNDI name. Use the get and set subcommands to view and change the values of the context service attributes.

When a resource is updated, the existing resource is shut down and recreated. If an application used the resource prior to the update, the application or the server must be restarted.

Ensure that the server is running. Remote subcommands require a running server.
List the context service resources by using the list-context-services subcommand.
View the attributes of a specific context service by using the get subcommand.
For example:
```
asdmin> get resources.context-service.concurrent/Context1.*
```

Set an attribute of the context service by using the set subcommand.
For example:

asdmin> set resources.context-service.concurrent/Context1.deployment-order=120

To Delete a Context Service

Use the delete-context-service subcommand in remote mode to delete an existing context service. Deleting a context service is a dynamic event and does not require server restart.

Before deleting a context service resource, all associations to the resource must be removed.

Ensure that the server is running. Remote subcommands require a running server.
List the context service resources by using the list-context-services subcommand.
If necessary, notify users that the context service is being deleted.
Delete the context service by using the delete-context-service subcommand.

Example 14-3 To Delete a Context Service

This example deletes the context service resource named concurrent/Context1.

asadmin> delete-context-service concurrent/Context1
Context service concurrent/Context1 deleted successfully.
Command delete-context-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help delete-context-service at the command line.

Configuring Managed Thread Factories

Managed thread factories are used by applications to create managed threads on demand. The threads are started and managed by the container. The context of the container is propagated to the thread executing the task.

Jakarta Concurrency specifies that certain default resources be made available to applications, and defines specific JNDI names for these default resources. Payara Server makes these names available through the use of logical JNDI names, which map Jakarta EE JNDI names to specific Payara Server resources. For managed thread factories, the mapping is as follows:
java:comp/DefaultManagedThreadFactory
This Jakarta Concurrency standard name is mapped to the concurrent/__defaultManagedThreadFactory resource.

To Create a Managed Thread Factory

Managed Thread Factories can be created by using Admin Console or Asadmin commands.

To create a new Managed Thread Factory in the Admin Console, go to Resources → Concurrent Resources → Managed Thread Factories → New:

New Managed Thread Factory

Because all JNDI names are in the java:comp/env subcontext, when specifying the JNDI name of a managed thread factory, use only the concurrent/ name format. For example, concurrent/Factory1.

For more information about the default managed thread factory resource included with Payara Server, see Default Concurrent Resources.

Creating a managed thread factory resource is a dynamic event and typically does not require server restart. Applications can use a resource as soon as it is created. However, if an application tried to use a resource before it was created, and that resource is created later, the application or the server must be restarted. Otherwise, the application will not be able to locate the resource.

Ensure that the server is running. Remote subcommands require a running server.
Create a managed thread factory by using the create-managed-thread-factory subcommand.
If necessary, notify users that the new resource has been created.

Example 14-4 To Create a Managed Thread Factory

This example creates a managed thread factory resource named concurrent/Factory1.

asadmin> create-managed-thread-factory concurrent/Factory1
Managed thread factory concurrent/Factory1 created successfully.
Command create-managed-thread-factory executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help create-managed-thread-factory at the command line.

To List Managed Thread Factories

Use the list-managed-thread-factories subcommand in remote mode to list the existing managed thread factory resources.

Ensure that the server is running. Remote subcommands require a running server.
List managed thread factory resources by using the list-managed-thread-factories subcommand.

Example 14-5 To List a Managed Thread Factory

This example lists managed thread factory resources on the default server instance, server.

asadmin> list-managed-thread-factories
concurrent/__defaultManagedThreadFactory
concurrent/Factory1
concurrent/Factory2
Command list-managed-thread-factories executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help list-managed-thread-factories at the command line.

To Update a Managed Thread Factory

You can change all of the settings for an existing managed thread factory resource except its JNDI name. Use the get and set subcommands to view and change the values of the managed thread factory attributes.

When a resource is updated, the existing resource is shut down and recreated. If applications used the resource prior to the update, the application or the server must be restarted.

Ensure that the server is running. Remote subcommands require a running server.
List the managed thread factory resources by using the list-managed-thread-factories subcommand.
View the attributes of a managed thread factory by using the get subcommand.
For example:
```
asdmin> get resources.managed-thread-factory.{resource-JNDI-name}.*
```

Set an attribute of the managed thread factory by using the set subcommand.
For example:

asdmin> set resources.managed-thread-factory.{resource-JNDI-name}.deployment-order=120

To Delete a Managed Thread Factory

The delete-managed-thread-factory asadmin command can be used to delete an existing managed thread factory. Deleting a managed thread factory is a dynamic event and does not require server restart. Before deleting a managed thread factory resource, all associations to the resource must be removed.

Before deleting a managed thread factory resource, all associations to the resource must be removed.

Ensure that the server is running. Remote subcommands require a running server.
List the managed thread factory resources by using the list-managed-thread-factories subcommand.
If necessary, notify users that the managed thread factory is being deleted.
Delete the managed thread factory by using the delete-managed-thread-factory subcommand.

Example 14-6 To Delete a Managed Thread Factory

This example deletes the managed thread factory resource named concurrent/Factory1.

asadmin> delete-managed-thread-factory concurrent/Factory1
Managed thread factory concurrent/Factory1 deleted successfully.
Command delete-managed-thread-factory executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help delete-managed-thread-factory at the command line.

Configuring Managed Executor Services

Managed executor services are used by applications to execute submitted tasks asynchronously. Tasks are executed on threads that are started and managed by the container. The context of the container is propagated to the thread executing the task.

Jakarta Concurrency specifies that certain default resources be made available to applications, and defines specific JNDI names for these default resources. Payara Server makes these names available through the use of logical JNDI names, which map Jakarta EE JNDI names to specific Payara Server resources. For managed executor services, the mapping is as follows:
java:comp/DefaultManagedExecutorService
This Jakarta Concurrency standard name is mapped to the concurrent/__defaultManagedExecutorService resource.

To Create a Managed Executor Service

Managed Executor Services can be created by using Admin Console or Asadmin commands.

To create a new Managed Executor Service in the Admin Console, go to Resources → Concurrent Resources → Managed Executor Services → New:

New Managed Executor Service

Use the create-managed-executor-service subcommand in remote mode to create a managed executor service resource.

Because all JNDI names are in the java:comp/env subcontext, when specifying the JNDI name of a managed executor service, use only the concurrent/`name format. For example, `concurrent/Executor1.

For more information about the default managed executor service resource included with Payara Server, see Default Concurrent Resources.

Creating a managed executor service resource is a dynamic event and typically does not require server restart. Applications can use a resource as soon as it is created. However, if an application tried to use a resource before it was created, and that resource is created later, the application or the server must be restarted. Otherwise, the application will not be able to locate the resource.

Ensure that the server is running. Remote subcommands require a running server.
Create a managed executor service by using the create-managed-executor-service subcommand.
If necessary, notify users that the new resource has been created.

Example 14-7 To Create a Managed Executor Service

This example creates a managed executor service resource named concurrent/Executor1.

asadmin> create-managed-executor-service concurrent/Executor1
Managed executor service concurrent/Executor1 created successfully.
Command create-managed-executor-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help create-managed-executor-service at the command line.

To List Managed Executor Services

The list-managed-executor-services asadmin command can be used to list the existing managed executor service resources.

Ensure that the server is running. Remote subcommands require a running server.
List managed executor service resources by using the list-managed-executor-services subcommand.

Example 14-8 To List a Managed Executor Service

This example lists managed executor service resources on the default server instance, server.

asadmin> list-managed-executor-services
concurrent/__defaultManagedExecutorService
concurrent/Executor1
concurrent/Executor2
Command list-managed-executor-services executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help list-managed-executor-services at the command line.

To Update a Managed Executor Service

You can change all of the settings for an existing managed executor service resource except its JNDI name. Use the get and set subcommands to view and change the values of the managed executor service attributes respectively.

When a resource is updated, the existing resource is shut down and recreated. If applications used the resource prior to the update, the application or the server must be restarted.

Ensure that the server is running. Remote subcommands require a running server.
List the managed executor service resources by using the list-managed-executor-services subcommand.
View the attributes of a managed executor service by using the get subcommand.
For example:
```
asdmin> get resources.managed-executor-service.{resource-JNDI-name}.*
```

Set an attribute of the managed executor service by using the set subcommand.
For example:

asdmin>  set resources.managed-executor-service.{resource-JNDI-name}.deployment-order=120

To Delete a Managed Executor Service

Use the delete-managed-executor-service subcommand in remote mode to delete an existing managed executor service. Deleting a managed executor service is a dynamic event and does not require server restart.

Before deleting a managed executor service resource, all associations to the resource must be removed.

Ensure that the server is running. Remote subcommands require a running server.
List the managed executor service resources by using the list-managed-executor-services subcommand.
If necessary, notify users that the managed executor service is being deleted.
Delete the managed executor service by using the delete-managed-executor-service subcommand.

Example 14-9 To Delete a Managed Executor Service

This example deletes the managed executor service resource named concurrent/Executor1.

asadmin> delete-managed-executor-service concurrent/Executor1
Managed executor service concurrent/Executor1 deleted successfully.
Command delete-managed-executor-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help delete-managed-executor-service at the command line.

Configuring Managed Scheduled Executor Services

Managed scheduled executor services are used by applications to execute submitted tasks asynchronously at specific times. Tasks are executed on threads that are started and managed by the container. The context of the container is propagated to the thread executing the task.

Jakarta Concurrency specifies that certain default resources be made available to applications, and defines specific JNDI names for these default resources. Payara Server makes these names available through the use of logical JNDI names, which map Jakarta EE JNDI names to specific Payara Server resources. For managed scheduled executor services, the mapping is as follows:
java:comp/DefaultManagedScheduledExecutorService
This Jakarta Concurrency standard name is mapped to the concurrent/__defaultManagedScheduledExecutorService resource.

To Create a Managed Scheduled Executor Service

Managed Scheduled Executor Services can be created by using Admin Console or Asadmin commands.

To create a new Managed Scheduled Executor Service in the Admin Console, go to Resources → Concurrent Resources → Managed Scheduled Executor Services → New:

New Managed Exector Service

Alternatively, the create-managed-scheduled-executor-service asadmin command can be used to create a managed scheduled executor service resource.

Because all JNDI names are in the java:comp/env subcontext, when specifying the JNDI name of a managed scheduled executor service, use only the concurrent/`name format. For example, `concurrent/ScheduledExecutor1.

For more information about the default managed scheduled executor service resource included with Payara Server, see Default Concurrent Resources.

Creating a managed scheduled executor service resource is a dynamic event and typically does not require server restart. Applications can use a resource as soon as it is created. However, if an application tried to use a resource before it was created, and that resource is created later, the application or the server must be restarted. Otherwise, the application will not be able to locate the resource.

Ensure that the server is running. Remote subcommands require a running server.
Create a managed scheduled executor service by using the create-managed-scheduled-executor-service subcommand.
If necessary, notify users that the new resource has been created.

Example 14-10 To Create a Managed Scheduled Executor Service

This example creates a managed scheduled executor service resource named concurrent/ScheduledExecutor1.

asadmin> create-managed-scheduled-executor-service concurrent/ScheduledExecutor1
Managed scheduled executor service concurrent/ScheduledExecutor1 created successfully.
Command create-managed-scheduled-executor-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help create-managed-scheduled-executor-service at the command line.

To List Managed Scheduled Executor Services

Use the list-managed-scheduled-executor-services subcommand in remote mode to list the existing managed scheduled executor service resources.

Ensure that the server is running. Remote subcommands require a running server.
List managed scheduled executor service resources by using the list-managed-scheduled-executor-services subcommand.

Example 14-11 To List a Managed Scheduled Executor Service

This example lists managed scheduled executor service resources on the default server instance, server.

asadmin> list-managed-scheduled-executor-services
concurrent/__defaultManagedScheduledExecutorService
concurrent/ScheduledExecutor1
concurrent/ScheduledExecutor2
Command list-managed-scheduled-executor-services executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help list-managed-scheduled-executor-services at the command line.

To Update a Managed Scheduled Executor Service

You can change all of the settings for an existing managed scheduled executor service resource except its JNDI name. Use the get and set subcommands to view and change the values of the managed scheduled executor service attributes.

When a resource is updated, the existing resource is shut down and recreated. If applications used the resource prior to the update, the application or the server must be restarted.

Ensure that the server is running. Remote subcommands require a running server.
List the managed scheduled executor service resources by using the list-managed-scheduled-executor-services subcommand.
View the attributes of a managed scheduled executor service by using the get subcommand.
For example:
```
asdmin>get resources.managed-scheduled-executor-service.{resource-JNDI-name}.*
```

Set an attribute of the managed scheduled executor service by using the set subcommand.
For example:

asdmin> set resources.managed-scheduled-executor-service.{resource-JNDI-name}.deployment-order=120

To Delete a Managed Scheduled Executor Service

Use the delete-managed-scheduled-executor-service subcommand in remote mode to delete an existing managed scheduled executor service. Deleting a managed scheduled executor service is a dynamic event and does not require server restart.

Before deleting a managed scheduled executor service resource, all associations to the resource must be removed.

Ensure that the server is running. Remote subcommands require a running server.
List the managed scheduled executor service resources by using the list-managed-scheduled-executor-service subcommand.
If necessary, notify users that the managed scheduled executor service is being deleted.
Delete the managed scheduled executor service by using the delete-managed-scheduled-executor-service subcommand.

Example 14-12 To Delete a Managed Scheduled Executor Service

This example deletes the managed scheduled executor service resource named concurrent/ScheduledExecutor1.

asadmin> delete-managed-scheduled-executor-service concurrent/ScheduledExecutor1
Managed scheduled executor service concurrent/ScheduledExecutor1 deleted successfully.
Command delete-managed-scheduled-executor-service executed successfully.

You can also view the full syntax and options of the subcommand by typing asadmin help delete-managed-scheduled-executor-service at the command line.