Memory leaks detection - Part II

In this post we will see how to relate the memory addresses with our source code to see in which line the memory leak is occurring. In the previous post, we saw some methods to detect memory leaks, of which we will take as a basis method 3 (which uses a program that fulfills the function of testnap and also leaves us a core file to analyze with mdb).

To develop this example, I used a file (fm_inv_pol_demo_leaks.c) with functions that cause memory leaks when using the macros and functions of the BRM API. This file is part of the fm_inv_pol.so library for testing purposes.

Memory leaks detection - Part I

Hello, today I am going to write how to detect memory leaks in our C / C ++ code of our BRM's fm libraries.

Many would have heard about Valgrind to detect memory leaks (among other functions it has), but unfortunately Valgrind does not work in Solaris SPARC, so we will have to use other tools when we work on a Solaris SPARC. In Oracle BRM documentation, Purify is mentioned, but since we have to pay a license, we are going to use something our OS already has so we don't have to pay for it.

To detect memory leaks (referred to * poid_t and * pin_flist_t) in the CM, the first thing we have to do is modify the CM's pin.conf adding this line:

- - disable_pcm_mempool 1

By adding that line in the CM's pin.conf we have disabled the memory pool that the CMs handle to process flist and poids, now the memory is allocated from the heap.

Detección de memory leaks - Parte IV (MTA)

En la entrada anterior (III) vimos como detectar memory leaks utilizando discover en una aplicación que ha sido desarrollada utilizando el framework MTA de BRM. Ahora veremos como hacerlo con otra herramienta: dbx (ésto también sirve para apliaciones que no han sido desarrolladas utilizando MTA, pero el post está orientado a este tipo de aplicaciones).

Reutilizando código, linkeo de librerías

He visto en muchos proyectos que se hace copy/paste de código y se lo va desparramando a lo largo de distintas librerias/apps en vez de tener una función en una sola librería e invocar esa función desde otras librerías/apps en vez de andar copiándola y pegándola por todos lados.

Por ejemplo: una función para obtener el poid de la /account dado el PIN_FLD_ACCOUNT_NO, eso se usa mucho en casi todas las librerías custom del proyecto y por lo general se la ve la misma función en todos los módulos, entonces, por qué tenerla por todos lados y no solo en uno e invocarla desde el resto de las librerías?

Ésto a veces se hace porque los desarrolladores no se ponen de acuerdo al principio para tener una librería con funciones que se utilizarán en casi todos los módulos o porque a veces  no saben como invocar una función que está en otra librería.

IEL: primeros pasos. Parte 1

En este post vamos a ver como dar nuestros primeros pasos con el IEL - BRM Event Loader.

Para configurar el IEL tenemos 2 archivos:

1. iel.cfg:aquí se configura el IEL en sí.
2. pin.conf: aquí se configuran los parametrós de conexión a BRM.

El archivo iel.cfg tiene la siguiente estructura (familiar con la estructura de un XML):

Setear el Developer Center para que reconozca los campos custom

Cuando creamos nuestros propios campos para BRM y luego los utilizamos en el Developer Center en algun opcode o campo de una clase custom vamos en donde iría el nombre del campo custom se ve UnknownFieldXXX, donde XXX es el id del campo. Así se ve en el Developer Center:

Performance: Usando el opcode PCM_OP_STEP_SEARCH

A veces cuando ejecutamos una búsqueda el resultado de la misma es de cientos o miles de registros (por ejemplo llamadas telefónicas) por lo que no es recomendable utilizar el PCM_OP_SEARCH (puede dar error en el dm_oracle por hacer que utilice toda la shared memory, o la performance decaerá) y es conveniente procesar esos registros en bloques mas pequeños, entonces utilizaremos el PCM_OP_STEP_SEARCH.

El uso del PCM_OP_STEP_SEARCH tiene 2 ventajas frente al PCM_OP_SEARCH:

Performance: configuración de bill items

En BRM podemos definir items custom (por ejemplo: /item/cargo_moratorio), dentro de éste tipo de item están los bill items.

No voy a entrar en detalle sobre como crear los bill items (ya esta explicado en la documentación online). Solamente voy a tocar el tema de la configuración de los mismos, específicamente la propiedad de precreate de los items.

La propiedad precreate especifica si BRM pre-creará o no el item para el tipo de servicio. En caso de que el valor sea true, el item se pre-creará en la base de datos (en la creación del servicio y en cada billing) y si el valor es false, el item se creará solamente cuando el evento ocurra.

PCM_OP_SEARCH obtener campos de mas de una clase

Muchas veces cuando hacemos un search (ya sea con PCM_OP_SEARCH o PCM_OP_STEP_SEARCH) en la base de datos necesitamos obtener campos de mas de una clase, para ello utilizaremos el PIN_FLD_LINKED_OBJ (es un array) dentro del input flist.

Supongamos que dado un número de cuenta queremos obtener los productos de dicha cuenta, el status del purchased, el nombre del deal, el numero de cuenta, el login y status del servicio de esos productos. Con esto estaríamos trayendo datos de 5 clases (/account, /deal, /service, /purchased_product y /product), con eso alcanza como ejemplo.

Aplicación MTA utilizando un archivo como entrada

Generalmente cuando desarrollamos una aplicación en la cual utilizacmos el framework MTA de BRM lo hacemos definiendo un template de búsqueda (en la base de datos) en la función pin_mta_init_search.

También existe la posibilidad de que nuestra aplicación MTA tome como entrada un archivo de texto que contiene un flist y procese los objetos que están en dentro del archivo (tal como se puede hacer en el pin_bill_accts y/o pin_inv_accts).

Para procesar los objetos que están en el archivo, en el pin_mta_init_search solamente debemos indicar el nombre del archivo y la cantidad de campos que tiene cada PIN_FLD_RESULTS del flist.