Configuración de métodos asíncronos EJB mediante scripts
Utilice los scripts de wsadmin para configurar los métodos asíncronos de Enterprise JavaBeans (EJB).
Antes de empezar
Acerca de esta tarea
Procedimiento
- Inicie la herramienta de scripts wsadmin utilizando el lenguaje de scripts Jython.
- Determine los atributos en el objeto de configuración EJBAsync que deben actualizarse. Puede actualizar los atributos siguientes en el objeto de
configuración EJBAsync:
Tabla 1. Atributos del objeto de configuración EJBAsync. En esta tabla se describen los atributos del objeto de configuración EJBAsync. Atributo Descripción maxThreads Especifica el número máximo de hebras que se utilizan en la ejecución de los métodos asíncronos de EJB. El valor predeterminado es 5.
workReqQSize Especifica el tamaño de la cola de solicitudes de trabajos. La cola de solicitudes de trabajo es un almacenamiento intermedio que contiene métodos asíncronos solicitados hasta que hay una hebra disponible donde ejecutarlos. La suma de los atributos maxThreads y workReqQSize es el número total de solicitudes de método en curso permitidas.
Por ejemplo, si el valor de maxThreads está establecido en 5 hebras, y el de workReqQSize está establecido en 50, el número total de solicitudes de método en progreso permisible será de 55.
El valor predeterminado es 0, que indica que el tamaño de cola lo gestiona el entorno de ejecución. El tiempo de ejecución actualmente utiliza un número mayor que 20 para maxThreads.
workReqQFullAction Especifica la acción que se realiza cuando se ha agotado la agrupación de hebras y la cola de solicitudes de trabajo está llena. Si se establece en 1, se produce una excepción en lugar de esperar a que haya disponible una hebra, o un lugar en la cola.
Si se establece en 0, la hebra que solicita la ejecución del método asíncrono espera a que haya disponible una hebra, o lugar en la cola.
El valor predeterminado es 0.
customWorkManagerJNDIName Especifica el nombre JNDI (Java™ Naming and Directory Interface) utilizado para buscar el gestor de trabajo definido personalizado en el espacio de trabajo. El valor predeterminado es null.
useCustomDefinedWM Especifica si se utiliza una instancia de gestor de trabajo definida de forma personalizada o la instancia de gestor de trabajo interna predeterminada. Cuando el atributo useCustomDefinedWM se establece en true, significa que se utiliza una instancia del gestor de trabajo personalizada. En este caso, se debe establecer el atributo customWorkManagerJNDIName y todos los demás atributos se ignoran.
Cuando el atributo useCustomDefinedWM se establece en false, el valor predeterminado, se utiliza la instancia del gestor de trabajo interna. En este caso, el atributo customWorkManagerJNDIName se ignora y todos los demás atributos se utilizan para ayudar a configurar la instancia del gestor de trabajo predeterminada.
El valor predeterminado es false (falso).
futureTimeout Especifica la cantidad de tiempo, en segundos, que el objeto futuro del lado del servidor, que se crea como resultado de la ejecución de un método asíncrono de activación y retorno, está disponible. El objeto futuro del lado del servidor no es válido después de llamar al método get(), y se devuelve un valor al cliente remoto. Para evitar fugas de memoria, debe llamar al método get() en el objeto futuro o especificar un valor de duración futuro positivo y distinto a cero. Un valor de duración futuro de cero indica que el objeto futuro nunca excede el tiempo de espera.
El valor predeterminado es 86400, lo que significa que el objeto futuro caduca y el servidor de aplicaciones lo limpia después de 24 horas y deja de estar disponible.
Se emite una excepción org.omg.CORBA.OBJECT_NOT_EXIST cuando se realiza una llamada al método get() después de que el objeto futuro caduque.
Supported configurations: Este valor sólo es aplicable para los clientes que llaman al enterprise bean utilizando una interfaz de empresa remota; el valor no se utiliza para la interfaz de empresa local o vistas sin interfaz. Cuando el trabajo asíncrono se ha completado, el servidor establece una alarma para la duración especificada sobre el objeto futuro en el lado del servidor. Cuando la alarma se activa, el servidor libera todos los recursos asociados con el objeto futuro, haciendo que no esté disponible para el cliente. Si el cliente llama al método get() en el objeto futuro antes de que transcurra la cantidad de tiempo de duración, la alarma se cancela y todos los recursos asociados con el objeto futuro se liberan.sptcfg
Supported configurations: Este atributo puede afectar al número de objetos futuros en el servidor. Utilice la estadística de PMI AsynchFutureObjectCount para determinar el número de FutureObjects abiertos en el servidor, que puede ayudarle a determinar si las aplicaciones están acumulando objetos futuros sin llamar al método get() en esos objetos. Para obtener más información, consulte Contadores de enterprise beans.sptcfg
- Obtenga una referencia al objeto de configuración EJBAsync correcto y almacénela en una variable.
Utilizando Jacl:
set async [$AdminConfig list EJBAsync]
En Jython:
async = AdminConfig.list('EJBAsync')
Si tiene un entorno de varios servidores, se devuelven varios objetos de configuración EJBAsync. Realice un bucle sobre la lista mediante programación y seleccione el objeto de configuración EJBAsync que corresponda al servidor que tenga que actualizar.
En un entorno de varios servidores, como alternativa realizar un bucle mediante programación sobre la lista de objetos EJBAsync, puede seleccionar manualmente el objeto EJBAsync correcto y copiarlo y pegarlo en la variable.
Por ejemplo, la salida del mandato AdminConfig list es:
(cells/myNode04Cell/nodes/myCellManager01/servers/dmgr|server.xml#EJBAsync_1)(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)
Puede copiar y pegar la referencia para el objeto EJBAsync necesario en la variable.
Utilizando Jacl:
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
En Jython:
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
- Actualice los atributos en el objeto de configuración EJBAsync.
Actualice los atributos en el objeto de configuración EJBAsync utilizando el mandato AdminConfig modify. Como entrada para el mandato, especifique la referencia de EJBAsync que ha obtenido en el paso anterior, y una lista de combinaciones de nombre de atributo (attributeName) y valor de atributo (attributeValue).
Para establecer un número máximo de hebras de 10, un tamaño de cola de 15 y un futureTimeout de 3600 segundos:
Utilizando Jacl:
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}" $AdminConfig modify $async $update
En Jython:
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
- Guarde los cambios de configuración.
En Jython:
AdminConfig.save()
Utilizando Jacl:
$AdminConfig save
- En un entorno sólo de despliegue de red, sincronice el nodo.
Utilizando Jacl:
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<your node>,*] $AdminControl invoke $sync1 sync
En Jython:
sync1 = AdminControl.completeObjectName('type=NodeSync,node=<your node>,*') AdminControl.invoke(sync1, 'sync')
Debe ejecutar la sincronización de nodos en estos ejemplos mientras está conectado al servidor.
Resultados


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_ejbAsynch_config
File name: txml_ejbAsynch_config.html