Create ManagedExecutorService, ManagedScheduledExecutorService, ManagedThreadFactory, ContextService in GlassFish 4 build 74 (TOTD #203)


Latest GlassFish 4 promoted build (74 at this time) has the first cut of Concurrency Utilities for Java EE (JSR 236) implementation integrated. An earlier blog provided an overview of the specification, lets see what can be actually done with this build.

This build introduce new commands to create ManagedExecutorService, ManagedScheduledExecutorService, ManagedThreadFactory, and ContextService.

A simple command execution as:

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

creates the configuration for a default ManagedExecutorService. Adding --help shows more details about the command:

create-managed-executor-service
    [--enabled=true]
    [--contextinfo=contextinfo]
    [--threadpriority=5]
    [--longrunningtasks=false]
    [--hungafterseconds=hungafterseconds]
    [--corepoolsize=0]
    [--maximumpoolsize=2147483647]
    [--keepaliveseconds=60]
    [--threadlifetimeseconds=0]
    [--taskqueuecapacity=2147483647]
    [--description=description]
    [--property=property]
    [--target=target]
    jndi_name

The created executor can then be injected into a Java EE component (say Servlet) as:

@Resource(name = "concurrent/myExecutor")
ManagedExecutorService executor;

or looked up using JNDI as:

InitialContext ctx = new InitialContext();
ManagedExecutorService executor = (ManagedExecutorService) ctx.lookup("concurrent/myExecutor");

A task can be defined as:

public class MyRunnableTask implements Runnable {

private int id;

public MyRunnableTask(int id) {
this.id = id;
}

@Override
public void run() {
try {
System.out.format("%d (runnable): starting", id);
System.out.format("%d (runnable): sleeping 2 seconds", id);
Thread.sleep(2000);
System.out.format("%d (runnable): complete", id);
} catch (InterruptedException ex) {
Logger.getLogger(TestResourceServlet.class.getName()).log(Level.SEVERE, null, ex);
}
}
}

Task can be submitted as:

Future<?> f = executor.submit(new MyRunnableTask(1));

OR

executor.execute(new MyRunnableTask(2));

A task may also be defined as:

public class MyCallableTask implements Callable<Product> {

private int id;

public MyCallableTask(int id) {
this.id = id;
}

@Override
public Product call() {
try {
System.out.format("%d (callable): starting", id);
System.out.format("%d (callable): sleeping 2 seconds", id);
Thread.sleep(2000);
System.out.format("%d (callable): complete", id);
} catch (InterruptedException ex) {
Logger.getLogger(TestResourceServlet.class.getName()).log(Level.SEVERE, null, ex);
}
return new Product(id);
}
}

where Product is a domain-specific class. In this case, the task is submited for execution as:

Future<Product> f2 = executor.submit(new MyCallableTask(3));
A ManagedScheduledExecutorService can be created as:

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

A ManagedThreadFactory can be created as:

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

A ContextService can be created as:

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

Note, this is the first integration and some of the options may not work. But you can definitely start playing around with basic stuff now.

The complete source code used in this Tip Of The Day (TOTD) is available here and will run on GlassFish 4 b74.

Comments:

Can't those artifacts be created using web.xml or an annotation? Having to go through asadmin is troublesome (apps have to provide readmes for every server?).

I hoped that administrated objects only were done with after J2ee, but here they are again...

Posted by guest on February 26, 2013 at 11:00 AM PST #

Yes, there is provision to create these elements using web.xml as well. Please read the latest spec at:

http://java.net/projects/concurrency-ee-spec/downloads

Posted by Arun Gupta on February 26, 2013 at 06:01 PM PST #

Are you sure this is possible? I just read the PFD (February 22, 2013), but I also don't see it.

E.g. 3.1.1.1.2 only gives a resource reference example:

<resource-env-ref>
<description>
This executor is used for the application’s reporter task.
This executor has the following requirements:
Context Info: Local Namespace
</description>
<resource-env-ref-name>
concurrent/LongRunningTasksExecutor
</resource-env-ref-name>
<resource-env-ref-type>
javax.enterprise.concurrent.ManagedExecutorService
</resource-env-ref-type>
</resource-env-ref>

With a note:

"Using the description for documenting the configuration attributes of the managed object is optional. The format used here is only an example. Future revisions of Java EE specifications may formalize usages such as this."

Then 3.1.4.2 gives examples and example attributes that a provider could use for their proprietary configuration tool, but I don't see any standard way to define e.g. a "ManagedExecutorService", just like we define say a data source in web.xml or with an annotation (@DataSourceDefinition).

I would have expected to see something like:

@ManagedExecutorService(name="myService", minThreads="5", maxThreads="10)

(or a corresponding entry in web.xml, ejb-jar.xml or application.xml)

Maybe I'm missing something?

Posted by guest on February 27, 2013 at 03:55 AM PST #

Can you give an example of this provision or an exact reference? I'm not really sure what you mean now.

Posted by guest on February 28, 2013 at 11:07 AM PST #

The quality-of-service attributes are not going to be defined by the specification, they are only provided as a sample. I posted a similar question on the users@concurrency-ee-spec.java.net at:

http://java.net/projects/concurrency-ee-spec/lists/users/archive/2013-02/message/32

The response was (not archived somehow):

-- quote --
I believe this was discussed in the expert group and decided not to do
so as we do not want to encourage each application to create their own
separate thread pools.
-- quote --

Posted by Arun Gupta on March 02, 2013 at 04:50 PM PST #

>I believe this was discussed in the expert group and decided not to do
>so as we do not want to encourage each application to create their own
>separate thread pools.

This is (IMHO) an outdated view that assumes there are always many applications running on a single AS. It could also be interpreted to say that developers are by definition cowboys and system administrators responsible persons, which is not only outdated by insulting as well.

In a modern and agile devops team, as well as for cloud deployments this hardly makes sense.

It's good that there IS an option to leave the setting to the AS, but it SHOULD NOT be the only option. It assumes a specific software process and organizational structure, which is just not a reality for every product and team out there.

Why else did Java EE introduce great innovations such as @DataSourceDefinition, the default datasource and the JMS equivalents?

This really is a step backwards for Java EE.

Posted by guest on March 10, 2013 at 03:35 AM PDT #

New to Glassfish and JavaEE, what options would I have for version 3.1.2.2 (build 5)

Thanks!

Posted by guest on March 21, 2013 at 06:06 AM PDT #

Did not see my original comment, how can I get the executor service to work with Glassfish V3?

Sorry if there is a delay on the comments being posted to the blog.

Posted by guest on March 21, 2013 at 07:45 AM PDT #

This is a feature of GlassFish 4 and will not work on prior releases of GlassFish.

Posted by Arun Gupta on March 22, 2013 at 12:44 PM PDT #

Dear,

I installed a glassfish 4 server.

I have simple application EAR.
1- module web-app that content : one servlet and one ServletcontextListener
2- module ejb, that content one local bean , that call a ManagedExecutorservice and submit a task(implemente runnable).

in my servlet, get method (call my ejb and then launch the method that execute a managedExecutorservice.submit)

in my servletcontextListener, contextInitialized method (call my ejb and then launch the method that execute a managedExecutorservice.submit)

- in my servlet, my task is correctly executed after call my servlet by http request

problem:
-in my ContextListener, my task is not executed after deploy my ear application. but application deployed successfully and well going on my contextListener(contextInitialized), but the server did not execute my task.

Thank you in advance

Posted by guest on September 18, 2013 at 03:16 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.


Java EE 7 Samples

Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today