oficial - ¿Dónde puedo configurar el grupo de subprocesos detrás de las llamadas @Asynchronous en Java EE 6?
oracle glassfish server 4.1 download (2)
Creo que el tiempo de espera se puede lograr al invocar Future.cancel (boolean) desde un método anotado @Timeout. Requiere mantener una referencia al futuro devuelto por el método asíncrono, Singleton-ejb se puede usar para esto.
@Stateless
public class AsyncEjb {
@Resource
private SessionContext sessionContext;
@Asynchronous
public Future<String> asyncMethod() {
...
//Check if canceled by timer
if(sessionContext.wasCancelCalled()) {
...
}
...
}
}
@Singleton
public class SingletonEjb {
@EJB
AsyncEjb asyncEjb;
Future<String> theFuture;
public void asyncMethod() {
theFuture = asyncEjb.asyncMethod();
//Create programatic timer
long duration = 6000;
Timer timer =
timerService.createSingleActionTimer(duration, new TimerConfig());
}
//Method invoked when timer runs out
@Timeout
public void timeout(Timer timer) {
theFuture.cancel(true);
}
}
Editar (nuevo a continuación):
En glassfish puede configurar el ejb-pool al marcar debajo de los atributos en la consola de administración
- Tamaño inicial y mínimo de la piscina
- Tamaño máximo de la piscina
- Cantidad de cambio de tamaño de la piscina
- Pool Idle Timeout
Recientemente descubrí que puedo hacer fácilmente cualquier método de bean de sesión asíncrono simplemente agregando la anotación @Asynchronous
.
P.ej
@Asynchronous
public Future<String> processPayment(Order order) throws PaymentException {
...
}
Sé que Java EE 7 agregó Utilidades de Concurrencia , pero en Java EE 6, ¿dónde está la configuración del grupo de @Asyncronous
métodos @Asyncronous
? ¿Hay alguna manera de establecer un tiempo de espera? ¿es un grupo de subprocesos fijos? un caché? ¿Cuál es su prioridad? ¿Es configurable en algún lugar del contenedor?
Aunque la solución que encontré fue probada solo en Java EE 7 / GlassFish 4.1, creo que también debería funcionar para GlassFish 3.x.
Hay una entrada de JIRA en java.net donde se enumeran las diferentes configuraciones. Como Oracle va a desconectar ese sitio, citaré aquí la publicación relevante (formato agregado):
La configuración está en domain.xml, por ejemplo,
<ejb-container> <property name="thread-core-pool-size" value="10"></property> <property name="thread-max-pool-size" value="100"></property> <property name="thread-queue-capacity" value="20"></property> <property name="thread-keep-alive-seconds" value="600"</property> <property name="allow-core-thread-timeout" value="false"></property> <property name="prestart-all-core-threads" value="false"></property> </ejb-container>
Todas las propiedades anteriores son opcionales. Sus valores predeterminados:
thread-core-pool-size: 16 thread-max-pool-size: 32 thread-queue-capacity: Integer.MAX_VALUE thread-keep-alive-seconds: 60 allow-core-thread-timeout: false prestart-all-core-threads: false
A través de ese hilo, también encontré una publicación de blog que explica cómo funcionan el tamaño del grupo principal y el tamaño máximo. Cita del punto importante:
En el pasado SUN declaró correctamente: "Así es exactamente como se supone que debe comportarse. Primero, los hilos crecen a CoreSize, luego se usa la cola, y luego, si la cola se llena, el número de hilos se expande de coreSize a maxSize. utiliza una cola ilimitada, la última parte nunca ocurre. Todo esto se describe en la documentación. Si desea una cola ilimitada pero más subprocesos, entonces aumente el tamaño del núcleo. De lo contrario, considere si una cola limitada es más adecuada a sus necesidades.