[openrtm-users 01225] Re: Howto check for data port buffer full error

Geoffrey Biggs geoffrey.biggs ＠ aist.go.jp
2010年 5月 18日 (火) 17:36:03 JST 

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<steffen.wittmeier ＠ in.tum.de>:
>>> 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<wittmeis ＠ in.tum.de>:
>>>>>
>>>>> 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/
>>>
>>>
>>
>>
>>
>

openrtm-users メーリングリストの案内