Problema con comunicación entre socket

¿Por qué mantener vivas las mismas instancias de STBFiler todo el tiempo?

Esos objetos no son costosos de crear, es más fácil crear uno para cada objeto transmitido. Cuando terminas de leer o escribir, ese filer muere y la siguiente vez, creas otro.

Si no, lo que deberías hacer es "resetear" los maps cuando tengas un idle time (cuando no estés leyendo o escribiendo objetos).

Sin mirar más el código, es lo que se me ocurre, a alto nivel.

Suerte

On 5/11/2020 00:19, Pablo Javier Mur wrote:

Hola,

tengo 2 aplicaciones escritas en Dolphin SmallTalk 7.1.14 que se comunican por socket. Para enviar datos utilizo el siguiente objeto:

(STBOutFiler on: socket writeStream) que se mantiene vivo durante toda la comunicación.

Para recibir datos utilizo el siguiente objeto:

((STBValidatingInFiler on: socket readStream)

validationBlock: [:className | true];

yourself) el cual también se mantiene vivo durante toda la conexión.

El problema es que las aplicaciones pueden estar conectadas durante horas y se envían objetos todo el tiempo. Los objetos STBFiler tienen atributos writeMap y readMap respectivamente los cuales va registrando todos los objetos que se reciben o envían lo cual hace que acumulen miles de instancias que no se usan pero no se eliminan porque están referenciadas por esos atributos. Eventualmente, en algún momento las aplicaciones caen. ¿Estoy haciendo algo mal? Les agradecería si pueden decirme si debo cambiar algo para no acumular objetos que deberían ser eliminados.

Saludos y muchas gracias.

--
--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
---
Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a [hidden email].
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/clubsmalltalk/7b016f99-8e31-4456-8dd9-f4efb74c16f2n%40googlegroups.com.

--

carlos e. ferro | senior developer |  caesar systems

[hidden email]

Hola te comento entre líneas,

El jue., 5 de nov. de 2020 4:30 PM, Pablo Javier Mur <[hidden email]> escribió:

Muchas gracias por tu respuesta Carlos, voy a probar creando un STBOutFiler y STBValidatingInFiler  para cada envío y recepción de mensaje.
Hasta Luego

El jueves, 5 de noviembre de 2020 a la(s) 09:16:56 UTC-3, Carlos Ferro escribió:

¿Por qué mantener vivas las mismas instancias de STBFiler todo el tiempo?

Esos objetos no son costosos de crear, es más fácil crear uno para cada objeto transmitido. Cuando terminas de leer o escribir, ese filer muere y la siguiente vez, creas otro.

Si no, lo que deberías hacer es "resetear" los maps cuando tengas un idle time (cuando no estés leyendo o escribiendo objetos).

Sin mirar más el código, es lo que se me ocurre, a alto nivel.

Suerte

On 5/11/2020 00:19, Pablo Javier Mur wrote:

Hola,

tengo 2 aplicaciones escritas en Dolphin SmallTalk 7.1.14 que se comunican por socket. Para enviar datos utilizo el siguiente objeto:

(STBOutFiler on: socket writeStream) que se mantiene vivo durante toda la comunicación.

Para recibir datos utilizo el siguiente objeto:

((STBValidatingInFiler on: socket readStream)

validationBlock: [:className | true];

No conozco exactamente tu app pero e; el Stbxxx se usa [ara serializar pero me parece que es más eficiente otros métodos, 

El validación es para saber si ;a clase existe en la imagen destino, una forma de hacer esto sería 

Smalltalk at: classname ifAbsent:[ self error: 'clase ',className no existe en esta imagen'].

No tengo acá la imagen [ero estoy seguro que Dp7 tiene el framework ston u. Otros seríalizadores.

Saludos

Desde el CEL

Juan Diaz Cortez

yourself) el cual también se mantiene vivo durante toda la conexión.

El problema es que las aplicaciones pueden estar conectadas durante horas y se envían objetos todo el tiempo. Los objetos STBFiler tienen atributos writeMap y readMap respectivamente los cuales va registrando todos los objetos que se reciben o envían lo cual hace que acumulen miles de instancias que no se usan pero no se eliminan porque están referenciadas por esos atributos. Eventualmente, en algún momento las aplicaciones caen. ¿Estoy haciendo algo mal? Les agradecería si pueden decirme si debo cambiar algo para no acumular objetos que deberían ser eliminados.

Saludos y muchas gracias.

--
--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
---
Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a [hidden email].
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/clubsmalltalk/7b016f99-8e31-4456-8dd9-f4efb74c16f2n%40googlegroups.com.

--

carlos e. ferro | senior developer |  caesar systems

[hidden email]

--
--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
---
Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a [hidden email].
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/clubsmalltalk/1c832fc7-c31d-451e-b069-ff9eaac6b414n%40googlegroups.com.

Perdón corrijo el código del email anterior

validationBlock: [:className |

Smalltalk at:className ifAbsent:[ ^self error:'clase  ',className, ' ausente en el image'.].

true.].

El jue., 5 de noviembre de 2020 17:05, Juan <[hidden email]> escribió:

Hola te comento entre líneas,

El jue., 5 de nov. de 2020 4:30 PM, Pablo Javier Mur <[hidden email]> escribió:

Muchas gracias por tu respuesta Carlos, voy a probar creando un STBOutFiler y STBValidatingInFiler  para cada envío y recepción de mensaje.
Hasta Luego

El jueves, 5 de noviembre de 2020 a la(s) 09:16:56 UTC-3, Carlos Ferro escribió:

¿Por qué mantener vivas las mismas instancias de STBFiler todo el tiempo?

Esos objetos no son costosos de crear, es más fácil crear uno para cada objeto transmitido. Cuando terminas de leer o escribir, ese filer muere y la siguiente vez, creas otro.

Si no, lo que deberías hacer es "resetear" los maps cuando tengas un idle time (cuando no estés leyendo o escribiendo objetos).

Sin mirar más el código, es lo que se me ocurre, a alto nivel.

Suerte

On 5/11/2020 00:19, Pablo Javier Mur wrote:

Hola,

tengo 2 aplicaciones escritas en Dolphin SmallTalk 7.1.14 que se comunican por socket. Para enviar datos utilizo el siguiente objeto:

(STBOutFiler on: socket writeStream) que se mantiene vivo durante toda la comunicación.

Para recibir datos utilizo el siguiente objeto:

((STBValidatingInFiler on: socket readStream)

validationBlock: [:className | true];

No conozco exactamente tu app pero e; el Stbxxx se usa [ara serializar pero me parece que es más eficiente otros métodos, 

El validación es para saber si ;a clase existe en la imagen destino, una forma de hacer esto sería 

Smalltalk at: classname ifAbsent:[ self error: 'clase ',className no existe en esta imagen'].

No tengo acá la imagen [ero estoy seguro que Dp7 tiene el framework ston u. Otros seríalizadores.

Saludos

Desde el CEL

Juan Diaz Cortez

yourself) el cual también se mantiene vivo durante toda la conexión.

El problema es que las aplicaciones pueden estar conectadas durante horas y se envían objetos todo el tiempo. Los objetos STBFiler tienen atributos writeMap y readMap respectivamente los cuales va registrando todos los objetos que se reciben o envían lo cual hace que acumulen miles de instancias que no se usan pero no se eliminan porque están referenciadas por esos atributos. Eventualmente, en algún momento las aplicaciones caen. ¿Estoy haciendo algo mal? Les agradecería si pueden decirme si debo cambiar algo para no acumular objetos que deberían ser eliminados.

Saludos y muchas gracias.

--
--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
---
Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a [hidden email].
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/clubsmalltalk/7b016f99-8e31-4456-8dd9-f4efb74c16f2n%40googlegroups.com.

--

carlos e. ferro | senior developer |  caesar systems

[hidden email]

--
--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
---
Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a [hidden email].
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/clubsmalltalk/1c832fc7-c31d-451e-b069-ff9eaac6b414n%40googlegroups.com.