[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168119#comment-15168119
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit 1de2f11f32bfa45ce0bad3b768b3d0f94aadb540 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1de2f11 ]

PROTON-1138: c++: Extend_CXX_FLAGS in CMakeLists.txt, don't overwrite user 
setting.


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168122#comment-15168122
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit a0fa5ce2323179d04726243f20d71daa78cbbb81 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a0fa5ce ]

PROTON-1138: c++: Remove value_* types, add amqp:: typedefs.

Consistently use either native C++ types or types defined in the proton:: 
namespace in the API.

The proton::amqp namespace contains typedefs and documentation explaining the
relationship between the AMQP type system and the C++/proton types. Its use is
optional, a C++ programmer will most likely use the C++ types directly. However
an AMQP programmer working in multiple languages may find it convenient to use
the AMQP type names consistently across languages.


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168121#comment-15168121
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit 8cbde66258b1389c85fc467d5c0ed65301587250 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8cbde66 ]

PROTON-1138: c++: Clean up error types.

Removed proton::closed_error
Renamed proton::io_error as proton::connection_engine::io_error
Replaced encode_error, decode_error and type_error with proton::conversion_error


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168117#comment-15168117
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit 71be1c6912ca77aa297492b019ee0ec0736f3546 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=71be1c6 ]

PROTON-1138: c++: Add proton::uuid, proton::timestamp and proton::decimal types.

- removed amqp_ prefixed uuid/timestamp/decimal types.
- added proton::byte_array base class for fixed-size types with no C++ 
equivalent.
- Got rid of public duration::milliseconds data member.
- Gave duration and timestamp consistent accessors, constructors and operator= 
for milliseconds values.
- Completed duration/timestamp arithmetic.

NOTE: changed duration to use int64_t instead of uint64_t. Durations can be
added and subtracted and negative durations can occur during calculations. Also
AMQP timestamp is defined as signed so we should be consistent.

UNIX time_t is traditionally unsigned because signed 32 bits is too small to
express a useful time range after the epoch. 64 bit timestamps (and durations)
do not require this restriction, signed timestamps can express time before and
after epoch.


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168118#comment-15168118
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit c7f3f558511ed07b8972304a2ba7a69dfc6b6354 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c7f3f55 ]

PROTON-1138: Simplify comparable class, make comparable inheritance private.

Simplified the comparable class.

- comparable is a private empty base class that exists only to instantiate 
operator friends of T.
- comparable is never used in any other way.
- for any compiler with even rudimentary empty-base-class support, this has 0 
run-time overhead.

I did some research to try and eliminate inheritance entirely. There are 2 well
known approaches.

1. boost::operators uses exactly the approach above.
2. std::rel_ops uses unconstrained templates that match anything with op == or 
< operator, we already agreed that approach is unsuitable for public API.

I tried type-trait approaches but could not find one that was better than the
above.  IMO inheritance is the right fit: It has no run-time overhead, it is
easy to understand, and we *want* "is-a" inheritance semantics: if `object` is
comparable then sub-classes of `object` should be comparable. (That is the part
that is hard to achieve with type-traits. When I realized I was trying to
reinvent inheritance I decided to let go.)


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168120#comment-15168120
 ] 

ASF subversion and git services commented on PROTON-1138:
-

Commit 6e8570898998beea953628238c897989a0344ca1 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6e85708 ]

PROTON-1138: c++: Make id_generator class private


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton-J Reactor sending delay

[Ken Giusti]

Andrew - are you calling send() from within a reactor callback?  Or from 
another thread?

I'm not very familiar with the Java reactor, but the C reactor has a method 
called pn_reactor_wakeup() which causes it to immediately return from the 
blocking select() call.

-K

- Original Message -
> From: "Andrew Buckley" 
> To: d...@qpid.apache.org, proton@qpid.apache.org
> Sent: Thursday, February 25, 2016 12:45:04 PM
> Subject: RE: Proton-J Reactor sending delay
> 
> Ah, thanks Robbie. Yes I do now notice the 3141ms timeout inside run(). Are
> there plans to make that timeout configurable? At least from my point of
> view, 3 seconds is quite a long time to wait between calling send and the
> action actually being performed, and applications using the Reactor do
> suffer a bit of a blow in performance because of this.
> 
> Thanks,
> -Andrew
> 
> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Monday, February 15, 2016 3:47 AM
> To: d...@qpid.apache.org; proton@qpid.apache.org
> Subject: Re: Proton-J Reactor sending delay
> 
> On 13 February 2016 at 00:28, Andrew Buckley  wrote:
> > I'm using the reactor with Proton-J and have noticed that there is a 2-4
> > second delay between when I call send() on a particular link and when that
> > transfer frame actually goes out. Is this expected behavior? If so, are
> > there plans to improve on this? And if not, have you seen this in any
> > other scenario and might you have any ideas what could be causing it?
> >
> > Thanks,
> > -Andrew Buckley
> >
> 
> Hi Andrew,
> 
> While im no expert on the reactor, I'd be surprised if that was expected, and
> I can't say I'm aware of it being mentioned before.
> 
> One thing that springs to mind from previous discussion [about proton-c
> reactor] is that when the reactor has a particular thread dedicated to
> running it, it sets a 3141ms timeout on its selector meaning it wakes up at
> that period when it is 'quiesced' (has nothing to do). Seems like perhaps
> that could be related given your note of 2-4sec.
> 
> Do you have an example showing the behaviour?
> 
> Robbie
> 
> (added proton@ as well, in case anyone only paying attention there has
> thoughts)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional
> commands, e-mail: dev-h...@qpid.apache.org
> 
> 

-- 
-K

RE: Proton-J Reactor sending delay

[Andrew Buckley]

Ah, thanks Robbie. Yes I do now notice the 3141ms timeout inside run(). Are 
there plans to make that timeout configurable? At least from my point of view, 
3 seconds is quite a long time to wait between calling send and the action 
actually being performed, and applications using the Reactor do suffer a bit of 
a blow in performance because of this.

Thanks,
-Andrew

-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] 
Sent: Monday, February 15, 2016 3:47 AM
To: d...@qpid.apache.org; proton@qpid.apache.org
Subject: Re: Proton-J Reactor sending delay

On 13 February 2016 at 00:28, Andrew Buckley  wrote:
> I'm using the reactor with Proton-J and have noticed that there is a 2-4 
> second delay between when I call send() on a particular link and when that 
> transfer frame actually goes out. Is this expected behavior? If so, are there 
> plans to improve on this? And if not, have you seen this in any other 
> scenario and might you have any ideas what could be causing it?
>
> Thanks,
> -Andrew Buckley
>

Hi Andrew,

While im no expert on the reactor, I'd be surprised if that was expected, and I 
can't say I'm aware of it being mentioned before.

One thing that springs to mind from previous discussion [about proton-c 
reactor] is that when the reactor has a particular thread dedicated to running 
it, it sets a 3141ms timeout on its selector meaning it wakes up at that period 
when it is 'quiesced' (has nothing to do). Seems like perhaps that could be 
related given your note of 2-4sec.

Do you have an example showing the behaviour?

Robbie

(added proton@ as well, in case anyone only paying attention there has thoughts)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional 
commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (PROTON-1148) recv example does not receive messages from ServiceBus topic.

[Randy Armstrong (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Armstrong closed PROTON-1148.
---
Resolution: Information Provided

Posted a request to us...@qpid.apache.org mailing list.

> recv example does not receive messages from ServiceBus topic.
> -
>
> Key: PROTON-1148
> URL: https://issues.apache.org/jira/browse/PROTON-1148
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11.0, 0.12.0
> Environment: Windows 10 Visual Studio 2105 Python 3.5 
>Reporter: Randy Armstrong
>
> I have two clients subscribing to a topic: 
> one using AMQPLite and the recv example in the proton code base. 
> The AMQPLite client receives notifications.
> The recv example does not.
> I am assuming that since I have verified that my broker is producing messages 
> and the recv example does not get then there is a bug in proton c code base.
> The URL i use for the recv example is:
> amqps://receiver:@opcfoundation-prototyping.servicebus.windows.net/MyTopic/Subscriptions/default
> I can provide a password if needed to replicate.
> Please tell me if this is not the right place to report these issue.
> I looked for a forum I could post to and could not find one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)