Durante la fase de registro, el intermediario descubre qué recursos (en este caso nodos) están disponibles y qué lils pueden proporcionarlos. La fase se inicia al iniciarse un grupo de ejecución. Las lils están cargadas en el arranque de un grupo de ejecución, y el intermediario las consulta para averiguar qué recursos pueden proporcionar.
Durante la fase de registro se crea una estructura CciFactory, cuando el nodo definido por el usuario invoca cniCreateNodeFactory.
Una instancia de un nodo Input definido por el usuario se crea cuando el mandato mqsistart inicia o reinicia el proceso de grupo de ejecución, o cuando un flujo de mensajes asociado con el nodo se difunde.
Durante esta fase se crea una estructura CciTerminal. Esta estructura se crea al invocar cniCreateTerminal.
La fase de proceso empieza cuando el intermediario invoca la función cniRun. El intermediario utiliza la función cniRun para determinar la manera de procesar un mensaje; esto incluye el hecho de determinar el dominio en que se define un mensaje y de invocar el analizador relevante para dicho dominio.
Desde la agrupación de hebras del flujo de mensajes se reclama una hebra, y se inicia en el método run del nodo de entrada. La hebra se conecta al gestor de colas del intermediario y retiene esta conexión durante su tiempo de vida. Una vez asignada una hebra, el nodo entra en un bucle de proceso de mensajes mientras espera recibir un mensaje, y no se detiene hasta que se recibe un mensaje. Si el flujo de mensajes está configurado para utilizar varias hebras, se activa el envío de hebras.
Los datos de mensaje pueden ahora propagarse en sentido descendente.
Un nodo de entrada definido por el usuario se destruye cuando el flujo de mensajes vuelve a difundirse o cuando se utiliza mqsistop para detener el proceso de grupo de ejecución. Puede destruir el nodo implementando la función cniDeleteNodeContext.
Cuando un nodo de entrada definido por el usuario se destruye de una de estas formas, es necesario liberar la memoria utilizada por el nodo, así como los recursos retenidos, como los zócalos.
Durante la fase de registro, un nodo Input definido por el usuario y escrito en Java se da a conocer al intermediario. El nodo se registra con el intermediario mediante el método getNodeName estático. Siempre que un intermediario se inicia, carga todas las clases Java relevantes. En este momento se invoca el método getNodeName estático y el intermediario registra el nodo de entrada con el nombre de nodo especificado en el método getNodeName. Si no especifica un nombre de nodo, el intermediario crea automáticamente un nombre para dicho nodo en función del paquete en que está incluido.
La utilización de un método estático en esta fase significa que el intermediario puede invocar el método antes de que se creen instancias del propio nodo.
Se crean instancias para un nodo de entrada Java definido por el usuario cuando un intermediario difunde un flujo de mensajes que contiene el nodo de entrada definido por el usuario. Al crearse instancias del nodo, se invoca el constructor de la clase de nodo de entrada.
Cuando se crean instancias de un nodo, se crean los terminales que se hayan especificado utilizando los métodos relevantes. Un nodo de entrada no tiene ningún terminal de entrada asociado, pero puede tener varios nodos de salida. Entre los terminales de salida se incluyen los terminales de salida (out), los terminales de anomalía y los de captación. Utilice el método createOutputTerminal del constructor de clases de nodos para crear todos los terminales de salida que necesite.
Si desea manejar las excepciones que se hayan vuelto a pasar al nodo de entrada, debe utilizar createOutputTerminal pare crear un terminal de captación para el nodo de entrada. Cuando el nodo de entrada capta un error, el terminal de captación lo procesa de la misma forma que lo haría un nodo MQInput regular. No obstante, puede permitir que vuelvan a pasarse al intermediario la mayoría de las excepciones, como las excepciones debidas a problemas de difusión, las cuales avisarán al usuario de cualquier posible error de configuración.
Como mínimo, la clase de constructor sólo necesita crear estos terminales de salida en el nodo de entrada. No obstante, si necesita inicializar valores de atributo, como definir el analizador que analizará inicialmente un mensaje pasado desde el nodo de entrada, deberá incluir tambien ahora ese código en el nodo de entrada.
El proceso de mensajes para un nodo de entrada empieza cuando el intermediario invoca el método run. El método run crea el mensaje de entrada, y debe contener la función de proceso para el nodo de entrada.
El método run se define en MbInputNodeInterface, que es la interfaz utilizada en un nodo de entrada definido por el usuario que la define como un nodo de entrada. Debe incluir un método run en el nodo. Si no incluye un método run en el nodo de entrada definido por el usuario, el código origen del nodo no se compilará.
Cuando un flujo de mensajes que contiene un nodo de entrada definido por el usuario se difunde correctamente, el intermediario invoca el método de implementación run del nodo y continúa invocando este método mientras espera que se procesen los mensajes.
Cuando se inicia un flujo de mensajes, el intermediario envía una sola hebra, que se invoca en el método run del nodo de entrada. Si se invoca el método dispatchThread, también podrán crearse otras hebras en el mismo método run. Estas nuevas hebras invocan inmediatamente el método run del nodo de entrada, y se les puede tratar del mismo modo que a la hebra original. El número de hebras nuevas que pueden crearse se define mediante el atributo additionalInstances. Debe asegurarse de que las hebras se envían después de crearse un mensaje y antes de propagarse. Esto garantiza que sólo haya una hebra cada vez esperando un nuevo mensaje.
Un usuario que difunda un flujo de mensajes utilizando un nodo de entrada definido por el usuario puede especificar que se utilicen varias hebras para dar servicio al flujo de mensajes. El nodo de entrada es responsable de implementar el modelo de trabajo con hebras elegido, pero el usuario no puede establecer restricciones sobre esta capacidad en el código. En cambio, debe asegurarse de que el código sea completamente reentrante y de que todas las funciones que el código invoque sean también completamente reentrantes.
Si desea ver más información acerca del modelo de trabajo con hebras para los nodos Input definidos por el usuario, consulte el apartado Trabajo con hebras.
Un nodo de entrada Java definido por el usuario se destruye al suprimirse el nodo o cerrarse el intermediario. No es necesario que incluya en el código información que especifique que el nodo debe suprimirse físicamente, ya que de esto se encarga el recopilador de basura.
No obstante, si desea que se le notifique de la supresión de algún nodo, puede utilizar el método onDelete. Es posible que desee utilizarlo si hay otros recursos aparte de los que se recopilarán como basura una vez suprimidos. Por ejemplo, si ha abierto un zócalo, éste no volverá a cerrarse correctamente cuando se suprima el nodo automáticamente. Puede incluir esta instrucción en el método onDelete para asegurarse de que el zócalo esté cerrado correctamente.
Conceptos relacionados
Analizadores definidos por el usuario
Extensiones definidas por el usuario
Tareas relacionadas
Creación de un nodo de entrada en Java
Creación de un nodo de entrada en C
Referencia relacionada
cniCreateInputTerminal
cniCreateNodeContext
cniCreateNodeFactory
cniRun
cniSetInputBuffer
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
as01391_ |