On 24/09/2020 7:29 pm, umohank wrote:
Hi Gordon,
I have tried Fetch API with Duration and without duration.
Without passing timeout duration:
if (receiver.fetch(request))
CPU is high, myclient_FetchWithoutDuration_CPUHigh.out
<http://qpid.2158936.n2.nabble.com/file/t396516/myclient_FetchWithoutDuration_CPUHigh.out>
With setting timeout duration:
if (receiver.fetch(request, Duration::SECOND * 1))
No CPU high issue, myclient_FetchWithDuration_NoCPUIssue.out
<http://qpid.2158936.n2.nabble.com/file/t396516/myclient_FetchWithDuration_NoCPUIssue.out>
any reason why?
Interesting. It would seem that on windows (on your build/platform at
least), the use of Duration::FOREVER is causing a problem with the wait
mechanism.
I don't use windows I'm afraid so I can't determine why that might be
exactly. Looking at the code it uses boost for both the time and
condition implementation on windows. (Specifically in the
Duration::FOREVER case it looks lie it creates a boost_posix_time::ptime
from boost::posix_time::max_date_time then passes that to
boost::condition_variable_any::timed_wait() which it would seem is
returning immediately in your case).
does C++ QPID Messaging support event driven mechanism?
Not sure what you mean. It does not have a way to specify a callback to
which messages are dispatched if that is what you mean. (However such a
dispatcher is simple to write yourself by fetching messages from one or
more receivers and passing them to the callbacks you want).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
