Created QPID-2402 to capture the API ambiguity and behavior, called a "bug" as I can use the API in the way it appears to be appropriate, and see "A problem which impairs or prevents the functions of the product."
On Thu, Feb 11, 2010 at 10:26 AM, Steve Huston <shus...@riverace.com> wrote: > I'm not Gordon or Rafi, but I thought we were trying to keep boost out > of the API as well. > > I do agree that qpid::sys::Duration should not be exposed; something > like qpid::messaging::Duration (which may just be a typedef for > uint64_t) would be better. > > -Steve > > > -----Original Message----- > > From: Andrew Stitcher [mailto:astitc...@redhat.com] > > Sent: Thursday, February 11, 2010 9:44 AM > > To: dev@qpid.apache.org > > Cc: Gordon Sim; Rafael Schloming > > Subject: Re: Is anyone working on C++ broker TTL ? > > > > > > On Wed, 2010-02-10 at 16:51 -0600, Kerry Bonin wrote: > > > OK... (for the C++ code) > > > > > > qpid::messaging.Message::setTTL( boost::uint64_t ttl ); > > > I was using this with a qpid::sys::Duration() object, which stores > > > time in a boost::posix_time::ptime object. This is > > documented to store > > > in units of nanoseconds. > > > > The Duration object (as several others) is meant to be > > entirely internal to the qpid code and not to "leak" to the > > client API. At least we should have explicitly decided it was > > part of the API if we want it there. > > > > It may look convenient, but it's really not been designed to > > be useful for any more than the internals of qpid. > > > > > > > > According to /cpp/src/qpid/broker/Message # 351-2, TTL is > > supposed to > > > be set in milliseconds. When I manually send ms, it works fine. > > > > > > I would recommend: > > > - document Message.setTTL units clearly - pick ms or ns > > > - if ms, then overload setTTL to take a Duration object so we can > > > use without error by converting in setTTL > > > > If we decided to keep the qpid time objects in the client API > > then we need to recast all times in the API to take (only) > > the qpid Duration and AbsTime types. > > > > > - if ns, then somewhere downstream (OutgoingMessage#351 ?) the ns > > > needs to get converted to ms > > > > This does raise the interesting issue of specifying time in > > the client API and doing it consistently - Gordon/Rafi do you > > have any thoughts WRT the new API? > > > > Andrew > > > > > > > > --------------------------------------------------------------------- > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
