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

Ando Noriaki n-ando ＠ aist.go.jp
2010年 5月 20日 (木) 19:12:02 JST 

Dear Steffen-san

ConnectorListenr is defined here.
http://openrtp.jp/openrtm/svn/OpenRTM-aist/tags/RELEASE_1_0_0/OpenRTM-aist/examples/SimpleIO/ConsoleIn.h

Does that answer your question?

2010/5/18 Steffen Wittmeier <steffen.wittmeier ＠ in.tum.de>:
> 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/
>
>



-- 
安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
    統合知能研究グループ 主任研究員, 博士(工学)
    〒305-8568 つくば市梅園1-1-1 中央第2
    e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org

Noriaki Ando, Ph.D.
    Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
    AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
    e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org

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