Problema con comunicación entre socket

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Problema con comunicación entre socket

Pablo Javier Mur
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.
Reply | Threaded
Open this post in threaded view
|

Re: Problema con comunicación entre socket

Carlos E. Ferro-2
¿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.


--
signature

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/eab4837e-d3df-b680-99e9-3521503a0fc8%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Problema con comunicación entre socket

Pablo Javier Mur
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];

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.
Reply | Threaded
Open this post in threaded view
|

Re: Problema con comunicación entre socket

Juan-2
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.

--
--
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/CAKizN9x07a2vny5bkehu%3D6%2B1niKerNWapoA9s3S2FfRqOHnW%3DA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Problema con comunicación entre socket

Juan-2
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.

--
--
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/CAKizN9yDwvoJJ8-%2B%3D4cff%2BtsKBMPqWP5be8jNZ%3Da2woQAEzWag%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Problema con comunicación entre socket

Pablo Javier Mur
dale, gracias por la respuesta. Voy a proceder como puse más arriba.
Saludos

El jueves, 5 de noviembre de 2020 a la(s) 17:28:18 UTC-3, mdc escribió:
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.

--
--
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/32497b28-ead6-4d2f-bb3c-4833a66feab8n%40googlegroups.com.