[openrtm-users 01226] Re: Howto check for data port buffer full error
Steffen Wittmeier
steffen.wittmeier ＠ in.tum.de
2010年 5月 18日 (火) 17:45:26 JST
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<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/
>>>>
>>>>
>>>
>>>
>>>
>>
>
--
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 メーリングリストの案内