[ NemesisRD 1.x ] Posible mejora para tratamiento de anomalias
1 view
Skip to first unread message
Eduardo Ramos Testillano
Apr 28, 2010, 3:26:02 AM4/28/10
to nemesi...@googlegroups.com
Hola,
Recientemente hasn puesto incidencia a los procesos sobre NRD debido a la aparición de una traza de error:
Quizá podríamos tener una solución válida para todos basada en implementar un metodo virtual del comunicador, un evento de "detectada trama incorrecta".
Dicho metodo tendría la implementación por defecto actual de NRD (sacar traza de error, cerrar el socket ?, ...), pero la aplicación podría reimplementarla vacía {;} para que la traza no saliera y simplemente los broadcast de congestion recibidos se ignorarían pasando desapercibidos. Incluso el metodo podría entregar en su interface, el buffer "anómalo" para que la aplicación pudiera parsearlo si lo estima necesario.
Dime si esta solución es factible o estoy obviando alguna situación imposible de controlar.
un saludo
-- Recientemente hasn puesto incidencia a los procesos sobre NRD debido a la aparición de una traza de error:
Error | sdp.Transport.cc (171) | thr: 0x41817960 | RuntimeException | Detectada situación 7e52a604fd711c33#-3Al margen de que la plataforma SDPPJ sea o no coherente en su tratamiento (parece que los mensajes de broadcast de congestión son un ejemplo de esto y NRD no los procesa), está claro que aquella los trata sin problemas y los procesos clásicos son perfectamente compatibles. No dudo que sea un fallo de diseño de la plataforma SDPPJ, pero su corrección allí tiene un impacto muy importante a parte de ser un tema delicado de "arreglar".
Quizá podríamos tener una solución válida para todos basada en implementar un metodo virtual del comunicador, un evento de "detectada trama incorrecta".
Dicho metodo tendría la implementación por defecto actual de NRD (sacar traza de error, cerrar el socket ?, ...), pero la aplicación podría reimplementarla vacía {;} para que la traza no saliera y simplemente los broadcast de congestion recibidos se ignorarían pasando desapercibidos. Incluso el metodo podría entregar en su interface, el buffer "anómalo" para que la aplicación pudiera parsearlo si lo estima necesario.
Dime si esta solución es factible o estoy obviando alguna situación imposible de controlar.
un saludo
--
Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
Cisco
Apr 28, 2010, 3:49:05 AM4/28/10
to NemesisRD 1.x
Hola.
No se si estás mezclando dos cosas distintas. ¿?
La traza '7e52a604fd711c33#-3' sale cuando hay buena suerte y se
consigue detectar el problema de que la plataforma SDP ha mandado un
mensaje incompleto (con lo que se debe invalidar ese socket) porque ya
no se podrá sacar correctamente ningún otro mensaje. Eso sale con
traza de warning, porque hay que dejar rastro de porqué se ha cerrado
el socket.
De todas formas quizás deberías revisar tu proceso cosas porque si
sale ese error es porque el que escribe en el socket se lo está
encontrando lleno, lo que implica que tu parte del socket no está
sacando con la suficiente rapidez, además hace poco creo que tenías
derivas en la duración de los temporizadores, muestra inequívoca de
que no estás devolviendo el control al núcleo de comunicaciones con la
suficiente periodicidad.
Después está el tema de las tramas sin formato que puede enviar la
plataforma SDP para notificar ciertos eventos, eso sale con el
identificador '7e52a604fd711c33#-4' y con el último parche mantiene el
socket abierto sin ningún problema, además se progresa el búfer
recibido mediante el método comm::Communicator::eventIgnoreBurst. La
traza también sale con nivel warning pero en este caso sí que se
podría bajar el nivel de severidad.
Un saludo.
> Recientemente hasn puesto incidencia a los procesos sobre NRD debido a la aparición de una traza de error:Error | sdp.Transport.cc (171) | thr: 0x41817960 | RuntimeException |Detectada situación 7e52a604fd711c33#-3Al margen de que la plataforma SDPPJ sea o no coherente en su tratamiento (parece que los mensajes de broadcast de congestión son un ejemplo de esto y NRD no los procesa), está claro que aquella los trata sin problemas y los procesos clásicos son perfectamente compatibles. No dudo que sea un fallo de diseño de la plataforma SDPPJ, pero su corrección allí tiene un impacto muy importante a parte de ser un tema delicado de "arreglar".
> 8KViewDownload
No se si estás mezclando dos cosas distintas. ¿?
La traza '7e52a604fd711c33#-3' sale cuando hay buena suerte y se
consigue detectar el problema de que la plataforma SDP ha mandado un
mensaje incompleto (con lo que se debe invalidar ese socket) porque ya
no se podrá sacar correctamente ningún otro mensaje. Eso sale con
traza de warning, porque hay que dejar rastro de porqué se ha cerrado
el socket.
De todas formas quizás deberías revisar tu proceso cosas porque si
sale ese error es porque el que escribe en el socket se lo está
encontrando lleno, lo que implica que tu parte del socket no está
sacando con la suficiente rapidez, además hace poco creo que tenías
derivas en la duración de los temporizadores, muestra inequívoca de
que no estás devolviendo el control al núcleo de comunicaciones con la
suficiente periodicidad.
Después está el tema de las tramas sin formato que puede enviar la
plataforma SDP para notificar ciertos eventos, eso sale con el
identificador '7e52a604fd711c33#-4' y con el último parche mantiene el
socket abierto sin ningún problema, además se progresa el búfer
recibido mediante el método comm::Communicator::eventIgnoreBurst. La
traza también sale con nivel warning pero en este caso sí que se
podría bajar el nivel de severidad.
Un saludo.
> Recientemente hasn puesto incidencia a los procesos sobre NRD debido a la aparición de una traza de error:Error | sdp.Transport.cc (171) | thr: 0x41817960 | RuntimeException |Detectada situación 7e52a604fd711c33#-3Al margen de que la plataforma SDPPJ sea o no coherente en su tratamiento (parece que los mensajes de broadcast de congestión son un ejemplo de esto y NRD no los procesa), está claro que aquella los trata sin problemas y los procesos clásicos son perfectamente compatibles. No dudo que sea un fallo de diseño de la plataforma SDPPJ, pero su corrección allí tiene un impacto muy importante a parte de ser un tema delicado de "arreglar".
> Quizá podríamos tener una solución válida para todos basada en implementar un metodo virtual del comunicador, un evento de "detectada trama incorrecta".
> Dicho metodo tendría la implementación por defecto actual de NRD (sacar traza de error, cerrar el socket ?, ...), pero la aplicación podría reimplementarla vacía {;} para que la traza no saliera y simplemente los broadcast de congestion recibidos se ignorarían pasando desapercibidos. Incluso el metodo podría entregar en su interface, el buffer "anómalo" para que la aplicación pudiera parsearlo si lo estima necesario.
> Dime si esta solución es factible o estoy obviando alguna situación imposible de controlar.
> un saludo--
>
>
>
> Dicho metodo tendría la implementación por defecto actual de NRD (sacar traza de error, cerrar el socket ?, ...), pero la aplicación podría reimplementarla vacía {;} para que la traza no saliera y simplemente los broadcast de congestion recibidos se ignorarían pasando desapercibidos. Incluso el metodo podría entregar en su interface, el buffer "anómalo" para que la aplicación pudiera parsearlo si lo estima necesario.
> Dime si esta solución es factible o estoy obviando alguna situación imposible de controlar.
> un saludo--
>
>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> firma.jpg
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> 8KViewDownload
Eduardo Ramos Testillano
Apr 28, 2010, 4:04:15 AM4/28/10
to nemesi...@googlegroups.com
ok.
No tengo trazas de esta prueba de TME, pero en cualquier caso se que suelen lanzar en nivel Error en vez de warning (no se vería la otra traza que comentas).
Lo que he visto es que les ha salido con el parche anterior del conector que tenía:
1) 2K para el chunksize (era cuando no se diferenciaba esto del maxPendingBytes).
2) no tenia las mejoras de timex con respecto al tratamiento ininterrumpido del pipe de planificacion de temporizadores
No se si esto explica la situación que comentas (y que yo había confundido con el broadcast de congestion).
un saludo
No tengo trazas de esta prueba de TME, pero en cualquier caso se que suelen lanzar en nivel Error en vez de warning (no se vería la otra traza que comentas).
Lo que he visto es que les ha salido con el parche anterior del conector que tenía:
1) 2K para el chunksize (era cuando no se diferenciaba esto del maxPendingBytes).
2) no tenia las mejoras de timex con respecto al tratamiento ininterrumpido del pipe de planificacion de temporizadores
No se si esto explica la situación que comentas (y que yo había confundido con el broadcast de congestion).
un saludo
--
Cisco
Apr 28, 2010, 4:28:53 AM4/28/10
to NemesisRD 1.x
Podría explicar una parte importante. Si esa versión no usaba lo de
poder configurar el MaxPendingBytes podría
ser que el control de congestión no actuara con la suficiente rapidez,
y por eso no estuvieras descartando un
número suficiente de mensajes.
On Apr 28, 10:04 am, Eduardo Ramos Testillano <era...@tid.es> wrote:
> ok.
> No tengo trazas de esta prueba de TME, pero en cualquier caso se que suelen lanzar en nivel Error en vez de warning (no se vería la otra traza que comentas).
> Lo que he visto es que les ha salido con el parche anterior del conector que tenía:
> 1) 2K para el chunksize (era cuando no se diferenciaba esto del maxPendingBytes).
> 2) no tenia las mejoras de timex con respecto al tratamiento ininterrumpido del pipe de planificacion de temporizadores
> No se si esto explica la situación que comentas (y que yo había confundido con el broadcast de congestion).
> un saludo
> El 28/04/2010 9:49, Cisco escribió:Hola. No se si estás mezclando dos cosas distintas. ¿? La traza '7e52a604fd711c33#-3' sale cuando hay buena suerte y se consigue detectar el problema de que la plataforma SDP ha mandado un mensaje incompleto (con lo que se debe invalidar ese socket) porque ya no se podrá sacar correctamente ningún otro mensaje. Eso sale con traza de warning, porque hay que dejar rastro de porqué se ha cerrado el socket. De todas formas quizás deberías revisar tu proceso cosas porque si sale ese error es porque el que escribe en el socket se lo está encontrando lleno, lo que implica que tu parte del socket no está sacando con la suficiente rapidez, además hace poco creo que tenías derivas en la duración de los temporizadores, muestra inequívoca de que no estás devolviendo el control al núcleo de comunicaciones con la suficiente periodicidad. Después está el tema de las tramas sin formato que puede enviar la plataforma SDP para notificar ciertos eventos, eso sale con el identificador '7e52a604fd711c33#-4' y con el último parche mantiene el socket abierto sin ningún problema, además se progresa el búfer recibido mediante el método comm::Communicator::eventIgnoreBurst. La traza también sale con nivel warning pero en este caso sí que se podría bajar el nivel de severidad. Un saludo. On Apr 28, 9:26 am, Eduardo Ramos Testillano<era...@tid.es>wrote:Hola, Recientemente hasn puesto incidencia a los procesos sobre NRD debido a la aparición de una traza de error:Error | sdp.Transport.cc (171) | thr: 0x41817960 | RuntimeException |Detectada situación 7e52a604fd711c33#-3Al margen de que la plataforma SDPPJ sea o no coherente en su tratamiento (parece que los mensajes de broadcast de congestión son un ejemplo de esto y NRD no los procesa), está claro que aquella los trata sin problemas y los procesos clásicos son perfectamente compatibles. No dudo que sea un fallo de diseño de la plataforma SDPPJ, pero su corrección allí tiene un impacto muy importante a parte de ser un tema delicado de "arreglar". Quizá podríamos tener una solución válida para todos basada en implementar un metodo virtual del comunicador, un evento de "detectada trama incorrecta". Dicho metodo tendría la implementación por defecto actual de NRD (sacar traza de error, cerrar el socket ?, ...), pero la aplicación podría reimplementarla vacía {;} para que la traza no saliera y simplemente los broadcast de congestion recibidos se ignorarían pasando desapercibidos. Incluso el metodo podría entregar en su interface, el buffer "anómalo" para que la aplicación pudiera parsearlo si lo estima necesario. Dime si esta solución es factible o estoy obviando alguna situación imposible de controlar. un saludo-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico anemes...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico anemesisrd-1...@googlegroups.comPara tener acceso a más opciones, visita el grupo enhttp://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDownload--
poder configurar el MaxPendingBytes podría
ser que el control de congestión no actuara con la suficiente rapidez,
y por eso no estuvieras descartando un
número suficiente de mensajes.
On Apr 28, 10:04 am, Eduardo Ramos Testillano <era...@tid.es> wrote:
> ok.
> No tengo trazas de esta prueba de TME, pero en cualquier caso se que suelen lanzar en nivel Error en vez de warning (no se vería la otra traza que comentas).
> Lo que he visto es que les ha salido con el parche anterior del conector que tenía:
> 1) 2K para el chunksize (era cuando no se diferenciaba esto del maxPendingBytes).
> 2) no tenia las mejoras de timex con respecto al tratamiento ininterrumpido del pipe de planificacion de temporizadores
> No se si esto explica la situación que comentas (y que yo había confundido con el broadcast de congestion).
> un saludo
Reply all
Reply to author
Forward
0 new messages