[openrtm-users 01234] Re: Fwd: Re: Re: Howto check for data port buffer full error
Steffen Wittmeier
steffen.wittmeier ＠ in.tum.de
2010年 5月 20日 (木) 21:21:05 JST
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<geoffrey.biggs ＠ aist.go.jp>
> To: Steffen Wittmeier<steffen.wittmeier ＠ in.tum.de>
>
> 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<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 メーリングリストの案内