Re: [ace-users] ACE_Reactor : The behaviour of "ACE_TP_Reactor" seemsto be different from the one described in TP_Reactor.h

info

    long timer_id = ACE_Reactor::instance()->schedule_timer(PTimer,
pNull, polling_time);  // <-- note: only "delay" is used,
no "interval"

Hi Tony,

You've misunderstood how to use ACE_TP_Reactor. The intended use is

one ACE_TP_Reactor object whose run_reactor_event_loop() method is

called by multiple threads. You are creating one reactor instance for

each thread.

Please see C++NPv2 chapter 4 for more information and examples of how

to use ACE_TP_Reactor properly. You can lern more about C++NPv2 at

http://www.riverace.com/acebooks/index.htm#cnpv2

-Steve

--

Steve Huston, Riverace Corporation

Total Lifecycle Support for Your Networked Applications

http://www.riverace.com

-----Original Message-----

From: ace-user...@list.isis.vanderbilt.edu

[mailto:ace-user...@list.isis.vanderbilt.edu] On Behalf Of Tony

Delvecchio

Sent: Friday, September 25, 2009 10:40 AM

To: ace-...@list.isis.vanderbilt.edu

Subject: [ace-users] ACE_Reactor : The behaviour of "ACE_TP_Reactor"

seemsto be different from the one described in TP_Reactor.h

    ACE VERSION: 5.3.1

    HOST MACHINE and OPERATING SYSTEM:

    THEMIS,  S.O. Solaris 9

    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:

    ---

    COMPILER NAME AND VERSION (AND PATCHLEVEL):

    C++ compiler Sun Forte 7

    CONTENTS OF $ACE_ROOT/ace/config.h:

    #ifndef ACE_CONFIG_H

  #include "ace/config-sunos5.8.h"

  #endif

    CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU

(unless

    this isn't used in this case, e.g., with Microsoft Visual
C++):

    ----

    AREA/CLASS/EXAMPLE AFFECTED:

    ACE_Reactor

    DOES THE PROBLEM AFFECT:

        COMPILATION?   NO

        LINKING?       NO

            On Unix systems, did you run
make realclean first?

            YES

        EXECUTION?     YES

        OTHER (please specify)? NO

[Please indicate whether ACE, your application, or both are affected.]

ACE_Reactor doesn't respect the timer_queue, so my application doesn't

respect some requirements (related to the timers)

    SYNOPSIS:

The behaviour of "ACE_TP_Reactor" seems to be different from
the one 

described in TP_Reactor.h

    DESCRIPTION:

My application uses many threads.

Some of them register a timer on the ACE_Reactor that is instanced

into a 

Thread class (named from now on My_Reactor_Thr).

In this class (My_Reactor_Thr) one (and only) ACE_TP_Reactor is

instanced as 

follows:

'constructor of the My_Reactor_Thr (That in the code is named ):

My_Reactor_Thr::My_Reactor_Thr(ACE_OS_Log_Msg_Attributes* attributes)

{

    attributes_ = attributes;

    ACE_TP_Reactor * pImpl = 0;

    ACE_NEW (pImpl,ACE_TP_Reactor);

    ACE_NEW(my_reactor_,ACE_Reactor (pImpl ,1));

    ACE_Reactor::instance (this->my_reactor_);

ACE_Reactor::instance()->timer_queue()->gettimeofday(&ACE_High_Res_Tim

er::gettimeofday_hr);

}

In the svcRun of the My_Reactor_Thr I have:

void* My_Reactor_Thr::svcRun(void* arg)

{

    My_Reactor_Thr* me = (My_Reactor_Thr*) arg;

    me->run();

    return 0;

}

And in the run method of the My_Reactor_Thr I have:

void My_Reactor_Thr::run(void)

{

    ACE_Log_Msg::inherit_hook (0,*attributes_);

    try

    {

        ACE_Reactor::instance()->run_reactor_event_loop();

    catch (...)

    {

        ACE_ERROR ((LM_ERROR, "My_Reactor_Thr::run
(%t):Exception 

Sconosciuta\n"));

    }

    return;

}

At last, in some threads I use the "schedule_timer" method in
order to

register a timer on ACE_Reactor as follows:

    long timer_id = 

ACE_Reactor::instance()->schedule_timer(PTimer,pNull,polling_time,poll

ing_time);

My application runs on a specific hardware and software platform.

Other applications run on other specific hardware and software

platform 

connected with mine.

Particularly, there is a couple of consoles which software is

connected by 

CORBA interface with my application.

My application monitors the states of the two consoles by polling them

once 

a second (by the ACE_Reactor internal timers management).

Generally, the ACE_Reactor works well and all the timer respect the 

schedule.

Sometimes consoles have problems and they work too slowly, causing a

trouble 

to my application, described below:

- When the time for the polling has come, the My_Reactor_Thr calls the

opportune "handle_timeout" (containing the polling action working
on

CORBA 

interface).

- Generally the polling action is completed in about 3 milliseconds,

but...

- ... When the console have problem the polling action is completed in

about 

1 minute!!!

- In the meanwhile the threads different by My_Reactor_Thr of my 

application, still work properly, but...

- ... the My_Reactor_Thr waites on CORBA interface the answer of the 

console.

- So, although the timer for the next handle_timeout is arrived, the 

My_Reactor_Thr is still waiting, not respecting the time schedule for

the 

other timers.

- Once the polling action is complete, the My_Reactor_Thr goes on and

works 

properly again, but a lot of action-timer are lost.

Since what is reported on "TP_Reactor.h":

"When an event occurs, the leader will pick a follower to become the

leader 

and go on to handle the event".

And

"It works by remembering the event handler that just got activated,

releasing the internal lock (so that some other thread can start

waiting in 

the event loop) and then dispatching the event handler outside the

context 

of the Reactor lock.",

I thought that once the timer for polling was trigged ("When an event

occurs"), the My_Reactor_Thr shall "goes on to handle the event"
and

in the 

meanwhile ACE_Reactor shall continue to manage the queque.

Instead, it seems that once the event occurs (the timer is triggered),

the 

leader handles the event until it is ended but, in the meanwhile, none

of 

the followers starts as new leader.

So, now I ask if:

- I have misunderstood the "TP_Reactor.h" or...

- There is something that can invalidate the correct behaviour (e.g. I

have 

bad instanced the TP_Reactor) or...

- If you can give me some hint useful for my situation (e.g. use the 

"run_reactor_loop" method in some different way or use some other

method to 

let ACE_Reactor go ahead without waiting).

Hope to receive an answer as soon as possible, best regards

Tony 

_______________________________________________

ace-users mailing list

ace-...@list.isis.vanderbilt.edu

http://list.isis.vanderbilt.edu/mailman/listinfo/ace-users

Re: [ace-users] ACE_Reactor : The behaviour of "ACE_TP_Reactor" seemsto be different from the one described in TP_Reactor.h

robert...@us.transport.bombardier.com