[Vortex] AW AW: Timout on using asynchron messages

[Ralf Konusch]

W: Timout on using asynchron messages
>
> > Hello Francis,
>
> Hi Ralf,

Hi Francis,

>
> > I think my main problem is that the tmlCore requirements of asynchron
> > / parallel messages via Vortex and the definition and implementation
> > of "timeout" in TmlCore don't fit with the automatic expansion
> mechanism designed to work better when heavy load is in place.
>
> Ok,
>
> > A few months ago:
> > When I reported you the "Limitation of 5 asynchron messages" problem
> a
> > few months ago, we didn't had that automatic expansion mechanism.
> > It was caused by he same test scenario , sending lots of asynchron /
> > parallel messages (each in a special tmlCore thread) via the same
> > channel but different ports.
> >
> > My expectance was/is a parallel messages processing regarding the
> tmlCore timeout definitions.
>
> Ok,
>
> > Let me explain you my simple tmlCore message implementation:
> >
> > - sender / vortex_channel_send_msg
> > - listener / vortex_channel_send_ans_rpy
> > - listener / vortex_channel_finalize_ans_rpy
> >
> > TmlCore API timeout description for a simple message:
> > Max. time between:
> >   sender / vortex_channel_send_msg and the ANS
> >   sender / vortex_channel_send_msg and the NUL
> >   last ANS and NUL
> >
> >
> >
> > Let me explain you my multiple answer tmlCore message implementation:
> >
> > - sender / vortex_channel_send_msg
> > - listener / vortex_channel_send_ans_rpy
> > - listener / vortex_channel_send_ans_rpy
> > - listener / vortex_channel_send_ans_rpy
> > - listener / vortex_channel_send_ans_rpy .
> > .
> > .
> > - listener / vortex_channel_finalize_ans_rpy
> >
> > TmlCore API timeout description for a multiple answer message:
> > Max. time between:
> >   sender / vortex_channel_send_msg and the first ANS
> >   any ANS and it's follower
> >   last ANS and NUL
> >
> >
> >
> > Let me explain you the tmlCore timeout definition:
> >
> > - The "timer" will be invoked after "vortex_channel_send_msg"
> returns.
> > - The "timer" will be resetted on each ANS reply (in case of multiple
> answer messages).
> > - The "timer" will be stopped on the final answer / NUL.
>
> Ok,
>
> >
> ######################################################################
> > ############ A parallel messages processing regarding the tmlCore
> > timeout definitions expects:
> >
> > - A quasi simultaneous vortex thread generation should be done on
> > "vortex_channel_send_msg" if all threads are busy (limited by the
> > time, the system needs to start a thread)
> > - Only a max. limitation of threads for the parallel message
> > processing
> > - Automatic thread destruction after a predefined time.
>
> Ok, I see. Current implementation is more designed to start consuming
> pending job but introducing some delays (especially checking automatic
> thread pool resize after finishing some work) instead of reacting right
> away in the case all threads are busy....
>
> ...I think there is a risk reacting too fast to a external connections,
> but, as you say, is what you need ;-)
>
> The latest update I've sent to you provides right away thread creation
> in the case thread_add_period is 0...however, current API do not allow
> configuring thread destruction after a configured period, because at
> this time that period is inferred by the thread_add_period.



The latest update will do a quasi simultaneous vortex thread generation in case of iThreadPoolAddPeriod==0 ?
Latest update is the version TML_WIN32_HEAD_1.1BLD327_2012-05-08_16-47-07.zip isn't it ?
I tried it out with iThreadPoolAddPeriod==0 but it shows the same behavior as the released
version - there is a time of 1 second between the asynchron messages.
It also shows the the same behavior with iThreadPoolAddPeriod==2 as the released
version.



>
> Let me work on a modification so you can configure how reacts the
> thread pool and to also allow configuring the period after which
> threads are finished...
>
> >
> ######################################################################
> > ############
> >
> >
> > The automatic expansion mechanism don't fit this because:
> > - A quasi simultaneous vortex thread generation is not done on
> > "vortex_channel_send_msg" also in case of using "iThreadPoolAddPeriod
> > == 0"
>
> Ok, with the latest modification this is now the case, I mean, when a
> task is received (message) thread pool resize is checked before
> attending that task....so it reacts faster...
>
> > - The "timer" will be invoked after "vortex_channel_send_msg"
> returns.
> > We don't have any knowledge about the time that will pass until the
> > message will be send
> >   via Vortex because of the automatic expansion implementation.
>
> Ok,
>
> > - It has a different motivation (heavy load).
>
> Ok,
>
> > Let me know if you think it is useful to produce results using the
> > last modifications with that tmlCore expectations.
>
> Ok, don't spend time on this because part of your expectation about the
> automatic thread pool resize are completed but others don't. Let me
> work in an API update that allows configuring all these details Ralf,
>
> I'll let you know my progress, Cheers!

I'm looking forward for that
>
> > Please let me know your impressions.
> >
> >
> > Cheers Ralf

Cheers

Ralf


> >
> >
> >
> > --
> > Ralf Konusch | Software Engineer | Email rk at wobe-systems.com | Phone
> > +49 431 5606 840 | Fax +49 431 5606 849 wobe-systems GmbH |
> > Schauenburgerstr. 116 | 24118 Kiel | Germany | Amtsgericht Kiel, HRB
> > 5783 Kiel | Executive Board: Wolfgang Baer, Oliver Dissars, Maik
> > Wojcieszak
>
> --
> Francis Brosnan Blázquez <francis.brosnan at aspl.es> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>
> AVISO LEGAL
>
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a
> secreto profesional, se prohíbe divulgarlos, en virtud de las leyes
> vigentes. Si usted no lo es y lo ha recibido por error o tiene
> conocimiento del mismo por cualquier motivo, le rogamos que nos lo
> comunique por este medio y proceda a destruirlo o borrarlo.
>
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos
> de que sus datos de carácter personal, recogidos de fuentes accesibles
> al público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).



--
Ralf Konusch | Software Engineer | Email rk at wobe-systems.com | Phone +49 431 5606 840 | Fax +49 431 5606 849
wobe-systems GmbH | Schauenburgerstr. 116 | 24118 Kiel | Germany | Amtsgericht Kiel, HRB 5783 Kiel | Executive Board: Wolfgang Baer, Oliver Dissars, Maik Wojcieszak