Hi Geoff,
I'll take a closer look at it and get back to you in case I have troubles.
Cheers
Steffen
On 05/20/2010 01:04 PM, Geoffrey Biggs wrote:
> It looks like I forgot to send this last mail to the list. For the
> benefit of anyone else struggling with the same issue...
>
> Geoff
>
> -------- Original Message --------
> Subject: Re: [openrtm-users 01226] Re: Howto check for data port buffer
> full error
> Date: Tue, 18 May 2010 17:53:32 +0900
> From: Geoffrey Biggs
> To: Steffen Wittmeier
>
> Hi Steffen
>
> The callbacks themselves are implemented as functors. Look in
> ConsoleIn.h in the examples. The ConnListener class implements a
> callback functor that can then be placed into any callback slot, as
> shown on lines 62 to 94 of ConsoleIn.cpp. Because it's a functor object,
> you're not limited to just the operator() method, but can put anything
> you like into it to support the behaviour you need.
>
> I hope that answers your question.
>
> Geoff
>
> On 18/05/10 17:45, Steffen Wittmeier wrote:
>
>> Hi Geoff,
>>
>> my problem basically is that I can not see where the callback of the
>> listener is defined. The ConnectorListener class only implements a
>> toString method and the operator(). So what method would be called in
>> the case of an error?
>>
>>
>> Steffen
>>
>> On 05/18/2010 10:36 AM, Geoffrey Biggs wrote:
>>
>>> Hi Steffen,
>>>
>>> The callback is invoked during the processing of the port, which may
>>> happen in a parallel task to your component's execution depending on the
>>> publishing policy you are using. For example, with the Periodic
>>> publishing policy, there is a task running in parallel to your component
>>> who's job it is to move data between the buffer of the output port and
>>> the actual connection to the other component(s). This publisher can
>>> detect several different error conditions; one of them is that the
>>> inport's buffer is full. When it detects that the buffer is full, it
>>> will call the "buffer full" callback of any attached listeners.
>>>
>>> Or at least, I think that's what it's supposed to do. I just checked the
>>> code (PublisherPeriodic.cpp, line 186) and noticed that it's not
>>> actually calling the callback at that point.
>>>
>>> Dr Ando: Is it the correct behaviour to not call the callback when an
>>> inport buffer is full? Currently the publisher only calls the callback
>>> for the local buffer being full.
>>>
>>> Geoff
>>>
>>> On 18/05/10 17:14, Steffen Wittmeier wrote:
>>>
>>>> Dear Ando-san,
>>>>
>>>> thanks for the quick reply. However, maybe I am wrong but the example
>>>> shows how to add a data listener to the port. How is the callback evoked
>>>> and how can I define the corresponding actions (e.g. wait and retry
>>>> send)?
>>>>
>>>>
>>>> Thanks again,
>>>> Steffen
>>>>
>>>> On 05/18/2010 10:08 AM, Ando Noriaki wrote:
>>>>
>>>>> Dear Sttefen-san
>>>>>
>>>>>
>>>>> 2010/5/18 Steffen Wittmeier:
>>>>>
>>>>>> Dear Ando-san,
>>>>>>
>>>>>> we are only using the RTSystemEditor for visualizing the current RTC
>>>>>> setup
>>>>>> and checking port properties. The entire startup of all components
>>>>>> and the
>>>>>> creation of the connections is handled directly in the code. So I
>>>>>> have to
>>>>>> find a way of setting all required properties within the code.
>>>>>>
>>>>>> What I tried now is to disable the overwrite mode of the buffer and
>>>>>> to set
>>>>>> the blocking timeout by:
>>>>>>
>>>>>> CORBA_SeqUtil::push_back(prof.properties, NVUtil::newNV(
>>>>>> "dataport.buffer.write.timeout", "0.1"));
>>>>>>
>>>>>> CORBA_SeqUtil::push_back(prof.properties,
>>>>>> NVUtil::newNV("dataport.buffer.write.full_policy", "block"));
>>>>>>
>>>>>>
>>>>>> That works - the remaining question now is: How do I define the
>>>>>> callback in
>>>>>> case the timeout occured when blocking? The ConnectorListener class
>>>>>> is an
>>>>>> abstract class. Do I have to derive my own listener class? How do I
>>>>>> define
>>>>>> the callback then?
>>>>>>
>>>>> Please forgive me for not providing enough documentation.
>>>>> An example of Connector(Data)Listener is here.
>>>>> http://openrtp.jp/openrtm/svn/OpenRTM-aist/tags/RELEASE_1_0_0/OpenRTM-aist/examples/SimpleIO/ConsoleIn.cpp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Noriaki Ando
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Steffen
>>>>>>
>>>>>> On 05/18/2010 06:59 AM, Ando Noriaki wrote:
>>>>>>
>>>>>>> Dear Steffen-san
>>>>>>>
>>>>>>> Please use new callbacks defined in ConnectorListener.h in that case.
>>>>>>> Two types of callback (listener) are provided in this scheme. One is
>>>>>>> ConnectorDataListener, which receives data from somewhere, and other
>>>>>>> is ConnectorListener, which does not receive any data.
>>>>>>>
>>>>>>> ConnecotrDataListener is as follows.
>>>>>>> * - ON_BUFFER_WRITE: At the time of buffer write
>>>>>>> * - ON_BUFFER_FULL: At the time of buffer full
>>>>>>> * - ON_BUFFER_WRITE_TIMEOUT: At the time of buffer write
>>>>>>> timeout
>>>>>>> * - ON_BUFFER_OVERWRITE: At the time of buffer overwrite
>>>>>>> * - ON_BUFFER_READ: At the time of buffer read
>>>>>>> * - ON_SEND: At the time of sending to InPort
>>>>>>> * - ON_RECEIVED: At the time of finishing
>>>>>>> sending to
>>>>>>> InPort
>>>>>>> * - ON_RECEIVER_FULL: At the time of bufferfull of
>>>>>>> InPort
>>>>>>> * - ON_RECEIVER_TIMEOUT: At the time of timeout of InPort
>>>>>>> * - ON_RECEIVER_ERROR: At the time of error of InPort
>>>>>>>
>>>>>>> ConnectorListener is as follows.
>>>>>>> * - ON_BUFFER_EMPTY: At the time of buffer empty
>>>>>>> * - ON_BUFFER_READTIMEOUT: At the time of buffer read timeout
>>>>>>> * - ON_BUFFER_EMPTY: At the time of empty of OutPort
>>>>>>> * - ON_SENDER_TIMEOUT: At the time of timeout of OutPort
>>>>>>> * - ON_SENDER_ERROR: At the time of error of OutPort
>>>>>>> * - ON_CONNECT: At the time of connection
>>>>>>> * - ON_DISCONNECT: At the time of disconnection
>>>>>>>
>>>>>>> However, ON_BUFFER_FULL and other _FULL callbacks are never called by
>>>>>>> default. Because overwrite mode is enabled in the default ring
>>>>>>> buffer. So DataPort never returns buffer-full error.
>>>>>>>
>>>>>>> RTSystemEditor, which will be released soon, will provide
>>>>>>> functionality in order to specify detail DataPort connector's
>>>>>>> properties.
>>>>>>>
>>>>>>> Please newest version of RTsystemEditor from
>>>>>>>
>>>>>>> http://www.openrtm.org/pub/OpenRTM-aist/dailybuild/tools/1.0.0/rtmtools-r114-1005061834.zip
>>>>>>>
>>>>>>>
>>>>>>> and try it.
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Noriaki Ando
>>>>>>>
>>>>>>>
>>>>>>> 2010/4/27 Steffen Wittmeier:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was looking for the onOverflow callback method as I know it from
>>>>>>>> OpenRTM
>>>>>>>> 0.42 but I could not find it in version 1.0. Did it move to some
>>>>>>>> other
>>>>>>>> class?
>>>>>>>>
>>>>>>>> Maybe I will try the 2nd option using the connectors in the
>>>>>>>> meantime.
>>>>>>>>
>>>>>>>>
>>>>>>>> Steffen
>>>>>>>>
>>>>>>>> On 04/27/2010 12:28 AM, Geoffrey Biggs wrote:
>>>>>>>>
>>>>>>>>> One possibility is using the OnOverflow callback on your port.
>>>>>>>>> When a
>>>>>>>>> buffer overflow occurs, this callback should be called. You can
>>>>>>>>> register
>>>>>>>>> a functor to this callback for the port in your component.
>>>>>>>>>
>>>>>>>>> Aside from that, it's possible the status is not being propagated
>>>>>>>>> correctly. The buffer is not held directly in the port object.
>>>>>>>>> It is
>>>>>>>>> held in the connection between the two ports - think of it as the
>>>>>>>>> buffer
>>>>>>>>> floating in the ether mystically. You could try exposing the
>>>>>>>>> connectors
>>>>>>>>> and checking their status directly to see if it's being propagated
>>>>>>>>> properly.
>>>>>>>>>
>>>>>>>>> Geoff
>>>>>>>>>
>>>>>>>>> On 26/04/10 22:17, Steffen Wittmeier wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> how can I check whether a data port buffer is full and sleep for a
>>>>>>>>>> retry?
>>>>>>>>>>
>>>>>>>>>> I tried to get the DataPortStatusList and iterated over the
>>>>>>>>>> list to
>>>>>>>>>> check the individual status. However, I always received PORT_OK,
>>>>>>>>>> even
>>>>>>>>>> when the buffer must have been full as I did not receive all
>>>>>>>>>> data on
>>>>>>>>>> the
>>>>>>>>>> other end of the connection. I also received PORT_OK when there
>>>>>>>>>> was no
>>>>>>>>>> connection between the provider and the consumer data port.
>>>>>>>>>>
>>>>>>>>>> Any help is appreciated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> Steffen Wittmeier
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Steffen Wittmeier
>>>>>> Lehrstuhl für Informatik VI
>>>>>> Technische Universität München
>>>>>> Boltzmannstraße 3, 85748 Garching
>>>>>>
>>>>>> Telefon : +89 289-18100
>>>>>> Telefax : +89 289-18107
>>>>>> E-Mail : steffen.wittmeier@in.tum.de
>>>>>> Internet: http://www6.in.tum.de/
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
It looks like I forgot to send this last mail to the list. For the
benefit of anyone else struggling with the same issue...
Geoff
-------- Original Message --------
Subject: Re: [openrtm-users 01226] Re: Howto check for data port buffer
full error
Date: Tue, 18 May 2010 17:53:32 +0900
From: Geoffrey Biggs
To: Steffen Wittmeier
Hi Steffen
The callbacks themselves are implemented as functors. Look in
ConsoleIn.h in the examples. The ConnListener class implements a
callback functor that can then be placed into any callback slot, as
shown on lines 62 to 94 of ConsoleIn.cpp. Because it's a functor object,
you're not limited to just the operator() method, but can put anything
you like into it to support the behaviour you need.
I hope that answers your question.
Geoff
On 18/05/10 17:45, Steffen Wittmeier wrote:
> Hi Geoff,
>
> my problem basically is that I can not see where the callback of the
> listener is defined. The ConnectorListener class only implements a
> toString method and the operator(). So what method would be called in
> the case of an error?
>
>
> Steffen
>
> On 05/18/2010 10:36 AM, Geoffrey Biggs wrote:
>> Hi Steffen,
>>
>> The callback is invoked during the processing of the port, which may
>> happen in a parallel task to your component's execution depending on the
>> publishing policy you are using. For example, with the Periodic
>> publishing policy, there is a task running in parallel to your component
>> who's job it is to move data between the buffer of the output port and
>> the actual connection to the other component(s). This publisher can
>> detect several different error conditions; one of them is that the
>> inport's buffer is full. When it detects that the buffer is full, it
>> will call the "buffer full" callback of any attached listeners.
>>
>> Or at least, I think that's what it's supposed to do. I just checked the
>> code (PublisherPeriodic.cpp, line 186) and noticed that it's not
>> actually calling the callback at that point.
>>
>> Dr Ando: Is it the correct behaviour to not call the callback when an
>> inport buffer is full? Currently the publisher only calls the callback
>> for the local buffer being full.
>>
>> Geoff
>>
>> On 18/05/10 17:14, Steffen Wittmeier wrote:
>>> Dear Ando-san,
>>>
>>> thanks for the quick reply. However, maybe I am wrong but the example
>>> shows how to add a data listener to the port. How is the callback evoked
>>> and how can I define the corresponding actions (e.g. wait and retry
>>> send)?
>>>
>>>
>>> Thanks again,
>>> Steffen
>>>
>>> On 05/18/2010 10:08 AM, Ando Noriaki wrote:
>>>> Dear Sttefen-san
>>>>
>>>>
>>>> 2010/5/18 Steffen Wittmeier:
>>>>> Dear Ando-san,
>>>>>
>>>>> we are only using the RTSystemEditor for visualizing the current RTC
>>>>> setup
>>>>> and checking port properties. The entire startup of all components
>>>>> and the
>>>>> creation of the connections is handled directly in the code. So I
>>>>> have to
>>>>> find a way of setting all required properties within the code.
>>>>>
>>>>> What I tried now is to disable the overwrite mode of the buffer and
>>>>> to set
>>>>> the blocking timeout by:
>>>>>
>>>>> CORBA_SeqUtil::push_back(prof.properties, NVUtil::newNV(
>>>>> "dataport.buffer.write.timeout", "0.1"));
>>>>>
>>>>> CORBA_SeqUtil::push_back(prof.properties,
>>>>> NVUtil::newNV("dataport.buffer.write.full_policy", "block"));
>>>>>
>>>>>
>>>>> That works - the remaining question now is: How do I define the
>>>>> callback in
>>>>> case the timeout occured when blocking? The ConnectorListener class
>>>>> is an
>>>>> abstract class. Do I have to derive my own listener class? How do I
>>>>> define
>>>>> the callback then?
>>>>
>>>> Please forgive me for not providing enough documentation.
>>>> An example of Connector(Data)Listener is here.
>>>> http://openrtp.jp/openrtm/svn/OpenRTM-aist/tags/RELEASE_1_0_0/OpenRTM-aist/examples/SimpleIO/ConsoleIn.cpp
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Noriaki Ando
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Steffen
>>>>>
>>>>> On 05/18/2010 06:59 AM, Ando Noriaki wrote:
>>>>>>
>>>>>> Dear Steffen-san
>>>>>>
>>>>>> Please use new callbacks defined in ConnectorListener.h in that case.
>>>>>> Two types of callback (listener) are provided in this scheme. One is
>>>>>> ConnectorDataListener, which receives data from somewhere, and other
>>>>>> is ConnectorListener, which does not receive any data.
>>>>>>
>>>>>> ConnecotrDataListener is as follows.
>>>>>> * - ON_BUFFER_WRITE: At the time of buffer write
>>>>>> * - ON_BUFFER_FULL: At the time of buffer full
>>>>>> * - ON_BUFFER_WRITE_TIMEOUT: At the time of buffer write
>>>>>> timeout
>>>>>> * - ON_BUFFER_OVERWRITE: At the time of buffer overwrite
>>>>>> * - ON_BUFFER_READ: At the time of buffer read
>>>>>> * - ON_SEND: At the time of sending to InPort
>>>>>> * - ON_RECEIVED: At the time of finishing
>>>>>> sending to
>>>>>> InPort
>>>>>> * - ON_RECEIVER_FULL: At the time of bufferfull of
>>>>>> InPort
>>>>>> * - ON_RECEIVER_TIMEOUT: At the time of timeout of InPort
>>>>>> * - ON_RECEIVER_ERROR: At the time of error of InPort
>>>>>>
>>>>>> ConnectorListener is as follows.
>>>>>> * - ON_BUFFER_EMPTY: At the time of buffer empty
>>>>>> * - ON_BUFFER_READTIMEOUT: At the time of buffer read timeout
>>>>>> * - ON_BUFFER_EMPTY: At the time of empty of OutPort
>>>>>> * - ON_SENDER_TIMEOUT: At the time of timeout of OutPort
>>>>>> * - ON_SENDER_ERROR: At the time of error of OutPort
>>>>>> * - ON_CONNECT: At the time of connection
>>>>>> * - ON_DISCONNECT: At the time of disconnection
>>>>>>
>>>>>> However, ON_BUFFER_FULL and other _FULL callbacks are never called by
>>>>>> default. Because overwrite mode is enabled in the default ring
>>>>>> buffer. So DataPort never returns buffer-full error.
>>>>>>
>>>>>> RTSystemEditor, which will be released soon, will provide
>>>>>> functionality in order to specify detail DataPort connector's
>>>>>> properties.
>>>>>>
>>>>>> Please newest version of RTsystemEditor from
>>>>>>
>>>>>> http://www.openrtm.org/pub/OpenRTM-aist/dailybuild/tools/1.0.0/rtmtools-r114-1005061834.zip
>>>>>>
>>>>>>
>>>>>> and try it.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Noriaki Ando
>>>>>>
>>>>>>
>>>>>> 2010/4/27 Steffen Wittmeier:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was looking for the onOverflow callback method as I know it from
>>>>>>> OpenRTM
>>>>>>> 0.42 but I could not find it in version 1.0. Did it move to some
>>>>>>> other
>>>>>>> class?
>>>>>>>
>>>>>>> Maybe I will try the 2nd option using the connectors in the
>>>>>>> meantime.
>>>>>>>
>>>>>>>
>>>>>>> Steffen
>>>>>>>
>>>>>>> On 04/27/2010 12:28 AM, Geoffrey Biggs wrote:
>>>>>>>>
>>>>>>>> One possibility is using the OnOverflow callback on your port.
>>>>>>>> When a
>>>>>>>> buffer overflow occurs, this callback should be called. You can
>>>>>>>> register
>>>>>>>> a functor to this callback for the port in your component.
>>>>>>>>
>>>>>>>> Aside from that, it's possible the status is not being propagated
>>>>>>>> correctly. The buffer is not held directly in the port object.
>>>>>>>> It is
>>>>>>>> held in the connection between the two ports - think of it as the
>>>>>>>> buffer
>>>>>>>> floating in the ether mystically. You could try exposing the
>>>>>>>> connectors
>>>>>>>> and checking their status directly to see if it's being propagated
>>>>>>>> properly.
>>>>>>>>
>>>>>>>> Geoff
>>>>>>>>
>>>>>>>> On 26/04/10 22:17, Steffen Wittmeier wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> how can I check whether a data port buffer is full and sleep for a
>>>>>>>>> retry?
>>>>>>>>>
>>>>>>>>> I tried to get the DataPortStatusList and iterated over the
>>>>>>>>> list to
>>>>>>>>> check the individual status. However, I always received PORT_OK,
>>>>>>>>> even
>>>>>>>>> when the buffer must have been full as I did not receive all
>>>>>>>>> data on
>>>>>>>>> the
>>>>>>>>> other end of the connection. I also received PORT_OK when there
>>>>>>>>> was no
>>>>>>>>> connection between the provider and the consumer data port.
>>>>>>>>>
>>>>>>>>> Any help is appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Steffen Wittmeier
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Steffen Wittmeier
>>>>> Lehrstuhl für Informatik VI
>>>>> Technische Universität München
>>>>> Boltzmannstraße 3, 85748 Garching
>>>>>
>>>>> Telefon : +89 289-18100
>>>>> Telefax : +89 289-18107
>>>>> E-Mail : steffen.wittmeier@in.tum.de
>>>>> Internet: http://www6.in.tum.de/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>