[jira] [Updated] (PROTON-209) Update README file(s) to more specific about required versions of tools

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-209:
---
Labels: docs  (was: )

> Update README file(s) to more specific about required versions of tools
> ---
>
> Key: PROTON-209
> URL: https://issues.apache.org/jira/browse/PROTON-209
> Project: Qpid Proton
>  Issue Type: Task
>Affects Versions: 0.3
>Reporter: Philip Harvey
>Priority: Minor
>  Labels: docs
>
> We should be more explicit about which version of the following tools are 
> required by Proton, either in the top level README or in READMEs in the 
> relevant sub-folders:
> - Python (see PROTON-199).
> - Swig
> - cmake? (the required version is specified in the CMakeLists.txt files but 
> maybe it would be polite to mention in the README too).
> - Maven? (or maybe we can omit this for same reasons as cmake version)
> - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc.



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

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

[jira] [Updated] (PROTON-416) Proton needs an icon

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-416:
---
Fix Version/s: Future

> Proton needs an icon
> 
>
> Key: PROTON-416
> URL: https://issues.apache.org/jira/browse/PROTON-416
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Chuck Rolke
> Fix For: Future
>
>
> The Proton project needs a cool icon. Qpid has the Q with the feather but 
> Qpid Proton doesn't have anything yet.
> Who has a graphic for us?



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

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

[jira] [Updated] (PROTON-282) Add support for transport unbind to proton-j

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-282:
---
Fix Version/s: Future

> Add support for transport unbind to proton-j
> 
>
> Key: PROTON-282
> URL: https://issues.apache.org/jira/browse/PROTON-282
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Reporter: Philip Harvey
> Fix For: Future
>
>
> As discussed on the mailing list recently (see 
> http://qpid.2158936.n2.nabble.com/Defining-the-behaviour-of-Proton-Engine-API-under-error-conditions-tp7590533.html),
>  Proton applications sometimes want to unbind a transport, e.g. following an 
> error, with the intention of binding to a new transport later on.
> proton-j does not currently support unbinding.



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

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

[jira] [Updated] (PROTON-135) Provide hooks in proton-c to allow override of malloc/free for internal types

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-135:
---
Labels: close-pending  (was: )

> Provide hooks in proton-c to allow override of malloc/free for internal types
> -
>
> Key: PROTON-135
> URL: https://issues.apache.org/jira/browse/PROTON-135
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.2
>Reporter: Ted Ross
>  Labels: close-pending
>
> It is desirable for engine applications (i.e. advanced developers) to be able 
> to provide a custom memory management solution for data types used in proton.
> I will follow up later with a proposal for how this might be done.  My 
> general thought is to allow an extension "plugin" to provide type-specific 
> 'allocate' and 'free' functions.



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

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

[jira] [Updated] (PROTON-1311) [proton-c] engine interface provides no access to Attach/max-message-size

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1311:

Fix Version/s: 0.16.0

> [proton-c] engine interface provides no access to Attach/max-message-size
> -
>
> Key: PROTON-1311
> URL: https://issues.apache.org/jira/browse/PROTON-1311
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.14.0
>Reporter: Chuck Rolke
> Fix For: 0.16.0
>
>
> A set function for new links is required.



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

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

[jira] [Updated] (PROTON-1175) Document BlockingConnection resource cleanup

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1175:

Labels: docs  (was: )

> Document BlockingConnection resource cleanup
> 
>
> Key: PROTON-1175
> URL: https://issues.apache.org/jira/browse/PROTON-1175
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
>  Labels: docs
> Fix For: 0.17.0
>
>
> The documentation is silent on resource cleanup for BlockingConnections.  
> Currently if the BlockingConnection is not closed, the file descriptors and 
> other reactor machinery are leaked.
> Standard Python techniques should be used to ensure resource clean up 
> (try..finally blocks etc.)
> Only the sync_client example hints this might be desirable, let alone 
> necessary.



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

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

[jira] [Updated] (PROTON-1175) Document BlockingConnection resource cleanup

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1175:

Fix Version/s: 0.17.0

> Document BlockingConnection resource cleanup
> 
>
> Key: PROTON-1175
> URL: https://issues.apache.org/jira/browse/PROTON-1175
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
>  Labels: docs
> Fix For: 0.17.0
>
>
> The documentation is silent on resource cleanup for BlockingConnections.  
> Currently if the BlockingConnection is not closed, the file descriptors and 
> other reactor machinery are leaked.
> Standard Python techniques should be used to ensure resource clean up 
> (try..finally blocks etc.)
> Only the sync_client example hints this might be desirable, let alone 
> necessary.



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

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

[jira] [Updated] (PROTON-1176) Core dump if reactor creation fails

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1176:

Labels: crash  (was: )

> Core dump if reactor creation fails
> ---
>
> Key: PROTON-1176
> URL: https://issues.apache.org/jira/browse/PROTON-1176
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
>  Labels: crash
> Fix For: 0.17.0
>
>
> If a BlockingConnection fails creating a reactor from Proton-C, the wrapper 
> constructor for the container fails on a null "impl" value, causing a core 
> dump rather than an exception.
> This can happen if the process runs out of file descriptors and cannot 
> allocate the self-pipes needed by the reactor.
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165



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

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

[jira] [Updated] (PROTON-1176) Core dump if reactor creation fails

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1176:

Fix Version/s: 0.17.0

> Core dump if reactor creation fails
> ---
>
> Key: PROTON-1176
> URL: https://issues.apache.org/jira/browse/PROTON-1176
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
> Fix For: 0.17.0
>
>
> If a BlockingConnection fails creating a reactor from Proton-C, the wrapper 
> constructor for the container fails on a null "impl" value, causing a core 
> dump rather than an exception.
> This can happen if the process runs out of file descriptors and cannot 
> allocate the self-pipes needed by the reactor.
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165



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

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

[jira] [Updated] (PROTON-1260) provide convenience operations for described types

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1260:

Fix Version/s: Future

> provide convenience operations for described types
> --
>
> Key: PROTON-1260
> URL: https://issues.apache.org/jira/browse/PROTON-1260
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Minor
> Fix For: Future
>
>
> Manipulating described types is not a frequent activity, but currently 
> requires using encoder/decoder classes to inspect/modify.  See 
> examples/cpp/selected_recv.cpp.  Same issue for server side code.



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

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

[jira] [Updated] (PROTON-1234) Windows IO modules need updating to match Posix improvements

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1234:

Fix Version/s: Future

> Windows IO modules need updating to match Posix improvements
> 
>
> Key: PROTON-1234
> URL: https://issues.apache.org/jira/browse/PROTON-1234
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.14.0
> Environment: Windows
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: Future
>
>
> The Posix IO and OpenSSL modules have had improvements not yet transferred to 
> the Windows side.  These include better error messages, logging and probably 
> some basic bug fixes.



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

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

[jira] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1312:

Labels: leak reproducer  (was: )

> BlockingConnection leaks Proton-C memory
> 
>
> Key: PROTON-1312
> URL: https://issues.apache.org/jira/browse/PROTON-1312
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9, 0.15.0
>Reporter: Cliff Jansen
>  Labels: leak, reproducer
> Fix For: 0.17.0
>
> Attachments: ml8.py
>
>
> The attached program leaks the underlying connection (the C proton
> object) associated with the BlockingConnection on each loop iteration
> on proton 0.9 as used by Satellite.  Without the receiver, it cleans
> up fine.
> On master, the program leaks both the reactor and the connection
> associated with the BlockingConnection for each loop.  The receiver
> creation can be commented out and it still leaks both objects.
> Other objects may leak too (presumably session), but I have not
> examined further.



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

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

[jira] [Updated] (PROTON-1264) on_receiver_open event after close

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1264:

Labels: close-pending  (was: )

> on_receiver_open event after close
> --
>
> Key: PROTON-1264
> URL: https://issues.apache.org/jira/browse/PROTON-1264
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Minor
>  Labels: close-pending
> Attachments: slow_attach
>
>
> If the peer is slow to respond with its attach frame from a receiver open and 
> the initiator gives up and closes the receiver, the eventual attach frame 
> from the peer will generate an on_receiver_open() event.



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

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

[jira] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1312:

Fix Version/s: 0.17.0

> BlockingConnection leaks Proton-C memory
> 
>
> Key: PROTON-1312
> URL: https://issues.apache.org/jira/browse/PROTON-1312
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9, 0.15.0
>Reporter: Cliff Jansen
>  Labels: leak, reproducer
> Fix For: 0.17.0
>
> Attachments: ml8.py
>
>
> The attached program leaks the underlying connection (the C proton
> object) associated with the BlockingConnection on each loop iteration
> on proton 0.9 as used by Satellite.  Without the receiver, it cleans
> up fine.
> On master, the program leaks both the reactor and the connection
> associated with the BlockingConnection for each loop.  The receiver
> creation can be commented out and it still leaks both objects.
> Other objects may leak too (presumably session), but I have not
> examined further.



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

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

[jira] [Updated] (PROTON-889) Thread safe pn_io_t

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-889:
---
Labels: close-pending  (was: )

> Thread safe pn_io_t
> ---
>
> Key: PROTON-889
> URL: https://issues.apache.org/jira/browse/PROTON-889
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Cliff Jansen
>  Labels: close-pending
>
> It has been pointed out before that the pn_io API does not allow thread safe 
> use of
>   pn_error_t *pn_io_error(pn_io_t *io)
>   bool pn_wouldblock(pn_io_t *io);
> For the moment, this JIRA serves as a reminder.  I am hesitant to propose a 
> specific solution without a solid outline of an actual implementation using 
> it.  We have the following use cases:
>   - moderately scalable single threaded implementation using Proton's 
> selector/selectable classes
>   - custom selector/IO just using the Proton engine (i.e. Dispatch, Qpid C++ 
> client/broker, no pn_io at all)
>   - external loop with direct calls to pn_io methods
> The ultimate performance would come from the custom IO route optimized for 
> the particular work load using engine primitives.  But given that Proton is 
> (at least mostly) thread safe on a per socket/connection basis (i.e. use by 
> Dispatch), it would seem that additional parallelization could be achieved 
> with various API changes (not just to pn_io methods).
> So, again with the disclaimer that an actual implementation should drive 
> this, some options could be
>   
>   6 new calls
>  pn_io_(io, selectable, buf, len);  (send/recv/write/read)
>  pn_selectable_wouldblock(selectable);
>  pn_selectable_error(selectable);
>   4 new calls
>  pn_io_(io, socket, buf, len, bool *wouldblock, pn_error_t *err)
> Assuming the existing single threaded use cases should not be burdened with 
> locking overhead, other related changes might include customized incref and 
> decref functions per pn_class_t, external custom collectors (and surely more).



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

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

[jira] [Updated] (PROTON-584) Proton-c transport reserves large buffers for brief use

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-584:
---
Fix Version/s: 0.17.0

> Proton-c transport reserves large buffers for brief use
> ---
>
> Key: PROTON-584
> URL: https://issues.apache.org/jira/browse/PROTON-584
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Cliff Jansen
> Fix For: 0.17.0
>
>
> When processing transfer frames for incoming messages, Proton requires a 
> temporary buffer holding the whole transfer frame briefly in contiguous space 
> in the transport before moving it to the engine proper which holds the 
> content in a separate memory area.
> pn_transport_capacity grows the buffer in the non-ssl case 
> (transport->input_buf), and openssl.c largely duplicates the code (including 
> the comment about "no limit") for ssl->inbuf for ssl connections.
> Either way, a large message will trigger reserving a similarly large buffer 
> for the rest of the life of the connection.
> Is it necessary for the transport to buffer the whole message body and hang 
> on to that memory?



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

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

[jira] [Updated] (PROTON-837) C reactor event samples, including external loop (libuv)

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-837:
---
Labels: close-pending  (was: )

> C reactor event samples, including external loop (libuv)
> 
>
> Key: PROTON-837
> URL: https://issues.apache.org/jira/browse/PROTON-837
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.9
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>  Labels: close-pending
>
> Provide sample programs to use the reactor event model.  Also provide
> an optional external loop "driver" to demonstrate the use of external
> event/io loops with Proton.



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

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

[jira] [Updated] (PROTON-348) Tests and examples need some platform helper functions

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-348:
---
Labels: close-pending  (was: )

> Tests and examples need some platform helper functions
> --
>
> Key: PROTON-348
> URL: https://issues.apache.org/jira/browse/PROTON-348
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
> Environment: All
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>  Labels: close-pending
>
> New functionality in examples and tests require platform neutral basic 
> functionality such as getopt (again) and time.  The existing code doesn't 
> build on Windows.  Presumably additional such functionality will be needed in 
> the future.



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

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

[jira] [Updated] (PROTON-1149) [Python binding] Python float values +inf and -inf do not work correctly as 32-bit AMQP float values on RHEL7

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1149:

Fix Version/s: Future

> [Python binding] Python float values +inf and -inf do not work correctly as 
> 32-bit AMQP float values on RHEL7
> -
>
> Key: PROTON-1149
> URL: https://issues.apache.org/jira/browse/PROTON-1149
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.13.0
>Reporter: Kim van der Riet
> Fix For: Future
>
>
> When run on RHEL 7, the 32-bit floating point values +inf (0x7f80) and 
> -inf (0xff80) cause a failure in the swig interface:
> {{OverflowError: in method 'pn_data_put_float', argument 2 of type 'float'}}
> Interestingly, the test values +NaN (0x7fc0) and -NaN(0xffc0) which 
> are also a part of the same test, work ok.
> This error does not occur on Fedora 22.
> System details:
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> kernel: 3.10.0-327.el7.x86_64
> Python: 2.7.5 (default, Oct 11, 2015 17:47:16)
> SWIG version 2.0.10



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

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

[jira] [Updated] (PROTON-251) When adding elements to an array, elements of a different type should cause an error

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-251:
---
Fix Version/s: Future

> When adding elements to an array, elements of a different type should cause 
> an error
> 
>
> Key: PROTON-251
> URL: https://issues.apache.org/jira/browse/PROTON-251
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Darryl L. Pierce
>Assignee: Kim van der Riet
> Fix For: Future
>
>
> If you create an array, you need to specify the type of elements for the 
> array. Then it seems logical that adding an element of a different type 
> should cause an error condition to occur and the element should not go into 
> the array.



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

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

[jira] [Updated] (PROTON-1160) [Python binding] decimal32 and decimal64 are sent byte reversed

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1160:

Fix Version/s: 0.17.0

> [Python binding] decimal32 and decimal64 are sent byte reversed
> ---
>
> Key: PROTON-1160
> URL: https://issues.apache.org/jira/browse/PROTON-1160
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: 0.17.0
>
>
> When sending {{decimal32}} and {{decimal64}} types to or from the Python 
> binding, the byte order of the numbers are reversed. This does not apply to 
> the {{decimal128}} type.
> It is noteworthy that this bug was exposed by qpid-interop-test when run 
> against the C++ binding.  In C++, these types are all based on a byte array, 
> whereas in the Python binding, {{decimal32}} and {{decimal64}} are derived 
> from Python types {{int}} and {{long}} respectively, while {{decimal128}} is 
> derived from Python type {{bytes}}.
> Decimal32:
> {noformat}
> sent:['0x', '0x40490fdb', '0xc02df854', '0xff7f']
> received:['0x', '0xdb0f4940', '0x54f82dc0', '0x7fff']
> {noformat}
> Decimal64:
> {noformat}
> sent:['0x', '0x400921fb54442eea', '0xc005bf0a8b145fcf', 
> '0xffef']
> received:['0x', '0xea2e4454fb210940', '0xcf5f148b0abf05c0', 
> '0xefff']
> {noformat}



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

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

[jira] [Updated] (PROTON-1091) [Python binding] AMQP null type not sent on wire according to AMQP specification

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1091:

Fix Version/s: 0.17.0

> [Python binding] AMQP null type not sent on wire according to AMQP 
> specification
> 
>
> Key: PROTON-1091
> URL: https://issues.apache.org/jira/browse/PROTON-1091
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: 0.17.0
>
>
> When sending AMQP type null as the content of a message, the Python binding 
> sends the message with no body at all, and similarly interprets a no-body 
> AMQP type message as a null type. This violates the AMQP 1.0 specification on 
> two counts:
> * A body MUST be present and be one of three types (section 3.2);
> * When sending an AMQP null type, there is an assigned AMQP type code (0x40) 
> which should be used.
> This causes interoperability issues with other clients. For example,  the C++ 
> client can't send a null type to a python client without a failure (or _visa 
> versa_).



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

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

[jira] [Updated] (PROTON-40) Detect and report errors for accessing settled deliveries

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-40:
--
Labels: api close-pending  (was: api)

> Detect and report errors for accessing settled deliveries
> -
>
> Key: PROTON-40
> URL: https://issues.apache.org/jira/browse/PROTON-40
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ted Ross
>Priority: Minor
>  Labels: api, close-pending
>
> If a proton client calls pn_disposition on more than one received delivery 
> between the sending of disposition frames, the next disposition frame will 
> reference only the first message in the batch.
> Ref:  This code fragment from pn_post_disp which uses the same value for 
> first and last id:
> return pn_post_frame(transport->disp, ssn_state->local_channel, 
> "DL[oIIo?DL[]]", DISPOSITION,
>  link->endpoint.type == RECEIVER, state->id, 
> state->id,
>  delivery->local_settled,
>  (bool)code, code);
> The result of this is that dispositions for messages are lost and senders 
> hang if there are credit windows of greater than one.  It would be ok, but 
> inefficient, to send multiple singleton dispositions.  In fact, proton simply 
> skips one or more disposition so the settlement of messages is incomplete.



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

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

[jira] [Updated] (PROTON-40) Detect and report errors for accessing settled deliveries

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-40:
--
Summary: Detect and report errors for accessing settled deliveries  (was: 
detect and report errors for accessing settled deliveries)

> Detect and report errors for accessing settled deliveries
> -
>
> Key: PROTON-40
> URL: https://issues.apache.org/jira/browse/PROTON-40
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ted Ross
>Priority: Minor
>  Labels: api, close-pending
>
> If a proton client calls pn_disposition on more than one received delivery 
> between the sending of disposition frames, the next disposition frame will 
> reference only the first message in the batch.
> Ref:  This code fragment from pn_post_disp which uses the same value for 
> first and last id:
> return pn_post_frame(transport->disp, ssn_state->local_channel, 
> "DL[oIIo?DL[]]", DISPOSITION,
>  link->endpoint.type == RECEIVER, state->id, 
> state->id,
>  delivery->local_settled,
>  (bool)code, code);
> The result of this is that dispositions for messages are lost and senders 
> hang if there are credit windows of greater than one.  It would be ok, but 
> inefficient, to send multiple singleton dispositions.  In fact, proton simply 
> skips one or more disposition so the settlement of messages is incomplete.



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

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

[jira] [Updated] (PROTON-40) detect and report errors for accessing settled deliveries

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-40:
--
Labels: api  (was: )

> detect and report errors for accessing settled deliveries
> -
>
> Key: PROTON-40
> URL: https://issues.apache.org/jira/browse/PROTON-40
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ted Ross
>Priority: Minor
>  Labels: api, close-pending
>
> If a proton client calls pn_disposition on more than one received delivery 
> between the sending of disposition frames, the next disposition frame will 
> reference only the first message in the batch.
> Ref:  This code fragment from pn_post_disp which uses the same value for 
> first and last id:
> return pn_post_frame(transport->disp, ssn_state->local_channel, 
> "DL[oIIo?DL[]]", DISPOSITION,
>  link->endpoint.type == RECEIVER, state->id, 
> state->id,
>  delivery->local_settled,
>  (bool)code, code);
> The result of this is that dispositions for messages are lost and senders 
> hang if there are credit windows of greater than one.  It would be ok, but 
> inefficient, to send multiple singleton dispositions.  In fact, proton simply 
> skips one or more disposition so the settlement of messages is incomplete.



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

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

[jira] [Updated] (PROTON-40) detect and report errors for accessing settled deliveries

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-40:
--
Summary: detect and report errors for accessing settled deliveries  (was: 
detect and report errors for acessing settled deliveries)

> detect and report errors for accessing settled deliveries
> -
>
> Key: PROTON-40
> URL: https://issues.apache.org/jira/browse/PROTON-40
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ted Ross
>Priority: Minor
>
> If a proton client calls pn_disposition on more than one received delivery 
> between the sending of disposition frames, the next disposition frame will 
> reference only the first message in the batch.
> Ref:  This code fragment from pn_post_disp which uses the same value for 
> first and last id:
> return pn_post_frame(transport->disp, ssn_state->local_channel, 
> "DL[oIIo?DL[]]", DISPOSITION,
>  link->endpoint.type == RECEIVER, state->id, 
> state->id,
>  delivery->local_settled,
>  (bool)code, code);
> The result of this is that dispositions for messages are lost and senders 
> hang if there are credit windows of greater than one.  It would be ok, but 
> inefficient, to send multiple singleton dispositions.  In fact, proton simply 
> skips one or more disposition so the settlement of messages is incomplete.



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

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

[jira] [Updated] (PROTON-285) MessengerTest#testSendBogus fails against proton-c

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-285:
---
Labels: close-pending test-failure  (was: )

> MessengerTest#testSendBogus fails against proton-c
> --
>
> Key: PROTON-285
> URL: https://issues.apache.org/jira/browse/PROTON-285
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Keith Wall
>Assignee: Rafael H. Schloming
>  Labels: close-pending, test-failure
>
> As highlighted in the following mailing list post:
> http://qpid.2158936.n2.nabble.com/Continually-failing-MessengerTests-WAS-NPE-from-MessengerTests-since-rev-1460174-tt7590662.html



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

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

[jira] [Updated] (PROTON-296) need a new message status

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-296:
---
Labels: api close-pending  (was: )

> need a new message status
> -
>
> Key: PROTON-296
> URL: https://issues.apache.org/jira/browse/PROTON-296
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: michael goulish
>  Labels: api, close-pending
>
> Currently, if a receiver settles messages rather than accepting or rejecting, 
> the status that the sender sees is PENDING.   That would seem to suggest that 
> it might change in the future, so the sender might keep checking back to see 
> if the status changes.  But the status isn't going to change.
> The only other available status for this situation is UNKNOWN, which has the 
> same problem.
> Seems like we could use a separate status integer, like SETTLED, that means 
> "the other side doesn't care, and that's final."



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

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

[jira] [Updated] (PROTON-312) [Proton-J] should Closed-Closed Sessions and Links be returned from Connection.sessionHead() and Connection.linkHead()

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-312:
---
Labels: close-pending  (was: )

> [Proton-J] should Closed-Closed Sessions and Links be returned from 
> Connection.sessionHead() and Connection.linkHead()
> --
>
> Key: PROTON-312
> URL: https://issues.apache.org/jira/browse/PROTON-312
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.4
>Reporter: Robbie Gemmell
>Assignee: Philip Harvey
>  Labels: close-pending
>
> When using Connection.sessionHead() and Connection.linkHead(), should 
> CLOSED-CLOSED Sessions and Links be returned? It appears that they are for 
> Sessions, but are not for Links, which is at best inconsistent.



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

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

[jira] [Updated] (PROTON-86) Automatically generate a message id on creation or clear

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-86:
--
Fix Version/s: Future

> Automatically generate a message id on creation or clear
> 
>
> Key: PROTON-86
> URL: https://issues.apache.org/jira/browse/PROTON-86
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: William Henry
> Fix For: Future
>
>
> Useful to have an automatically generated unique id for a message. That way 
> users have one by default but can always set it explicitly using set_id if 
> needed.



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

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

[jira] [Updated] (PROTON-86) Automatically generate a message id on creation or clear

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-86:
--
Issue Type: Improvement  (was: Bug)

> Automatically generate a message id on creation or clear
> 
>
> Key: PROTON-86
> URL: https://issues.apache.org/jira/browse/PROTON-86
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: William Henry
>
> Useful to have an automatically generated unique id for a message. That way 
> users have one by default but can always set it explicitly using set_id if 
> needed.



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

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

[jira] [Updated] (PROTON-338) Support distributed transactions

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-338:
---
Labels: close-pending  (was: )

> Support distributed transactions 
> -
>
> Key: PROTON-338
> URL: https://issues.apache.org/jira/browse/PROTON-338
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: proton-j
>Affects Versions: 0.5
>Reporter: Kim Palko
>  Labels: close-pending
>
> Distributed transactions should be supported with proton-j.



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

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

[jira] [Updated] (PROTON-220) Create a set of "glass box" tests to quantify the performance of the proton codebase.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-220:
---
Labels: perf testing  (was: perfomance test)

> Create a set of "glass box" tests to quantify the performance of the proton 
> codebase.
> -
>
> Key: PROTON-220
> URL: https://issues.apache.org/jira/browse/PROTON-220
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c, proton-j
>Reporter: Ken Giusti
>Assignee: michael goulish
>  Labels: perf, testing
> Fix For: 0.17.0
>
>
> The goal of these tests would be to detect any performance degradation 
> inadvertently introduced during development.   These tests would not be 
> intended to provide any metrics regarding the "real world" behavior of 
> proton-based applications.  Rather, these tests are targeted for use by the 
> proton developers to help gauge the effect their code changes may have on 
> performance.
> These tests should require no special configuration or setup in order to run. 
>  It should be easy to run these test as part of the development process.  The 
> intent would be to have developer run the tests prior to making any code 
> changes, and record the metrics for comparison against the results obtained 
> after making changes to the code base.
> As described by Rafi:
> "I think it would be good to include some performance metrics that isolate
> the various components of proton. For example having a metric that simply
> repeatedly encodes/decodes a message would be quite useful in isolating the
> message implementation. Setting up two engines in memory and using them to
> blast zero sized messages back and forth as fast as possible would tell us
> how much protocol overhead the engine is adding. Using the codec directly
> to encode/decode data would also be a useful measure. Each of these would
> probably want to have multiple profiles, different message content,
> different acknowledgement/flow control patterns, and different kinds of
> data.
> I think breaking out the different dimensions of the implementation as
> above would provide a very useful tool to run before/after any performance
> sensitive changes to detect and isolate regressions, or to test potential
> improvements."



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

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

[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-144:
---
Labels: perf  (was: message performance)

> Reduce byte overhead for small payloads
> ---
>
> Key: PROTON-144
> URL: https://issues.apache.org/jira/browse/PROTON-144
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.2, 0.3
>Reporter: Affan Dar
>  Labels: perf
> Fix For: 0.17.0
>
>
> In constrained bandwidth scenarios (e.g. on a cellular data network) any byte 
> overhead is very costly.
> From the traces for a simple app, we are seeing a large overhead (>100 bytes) 
> in the message payload for sending a two byte message. It seems like there 
> are some default properties like the to and reply-to addresses that the 
> proton client stamps onto a message and also there is padding on the actual 
> two byte payload itself. 
> To be able to successfully embed the proton lib in such resource constrained 
> devices the byte overhead needs to be trimmed down as much as the protocol 
> allows.
> ---
> Details of test app
> ---
> The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN 
> updated usually once a day although commits have slowed since the push for 
> 0.2 and libopenssl version 1.0.0e-34.17.1. 
> The debugging output is all from proton, to get the debugging output set the 
> Env variable "PN_TRACE_FRM=1"
> The test is done connecting to localhost and sending a message across as 
> simply as possible:
> client:
> pn_messenger_t *messenger = pn_messenger("b");
> pn_messenger_start(messenger);
> pn_message_t *message = pn_message();
> pn_message_set_address(message, "amqps://0.0.0.0/a");
> char data[2] = {(unsigned char)0xff, (unsigned char)0xff};
> pn_message_load_data(message, data, 2);
> pn_messenger_put(messenger, message);
> pn_messenger_send(messenger);
>  
> server code:
> pn_messenger_t *messenger = pn_messenger("a");
> pn_messenger_start(messenger);
> pn_messenger_subscribe(messenger, "amqps://~0.0.0.0");
> pn_message_t *message = pn_message();
> pn_messenger_recv(messenger, 1);
> pn_messenger_get(messenger, message);
> size_t size = 2;
> char data[2];
> pn_message_save_data(message, data, );
>  
> server  output:
> Accepted from localhost.localdomain:36331
> -> SASL
> [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
> [0x622180:0] -> SASL-OUTCOME @68 [0]
> -> AMQP
> [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null]
> <- SASL
> [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""]
> <- AMQP
> [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, 
> null]
> [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024]
> [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, 
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, 
> false, null, null], null, null, 0]
> [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024]
> [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, 
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, 
> false, null, null], null, null, 0]
> [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false]
> [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, 
> true, false] (133) 
> "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff"
>  
> client output:
> Connected to 0.0.0.0:5671
> -> SASL
> [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""]
> <- SASL
> [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
> [0x620020:0] <- SASL-OUTCOME @68 [0]
> <- AMQP
> [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null]
> -> AMQP
> [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, 
> null]
> [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024]
> [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, 
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, 
> false, null, null], null, null, 0]
> [0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024]
> [0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, 
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, 
> false, null, null], null, null, 0]
> [0x61a840:1] <- FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false]
> [0x61a840:1] -> TRANSFER @20 [1, 

[jira] [Updated] (PROTON-1253) PHP client using C API send no empty frames - ActiveMQ broker drops the connection due to Inactivity after 60 seconds

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1253:

Fix Version/s: (was: 0.17.0)

> PHP client using C API send no empty frames - ActiveMQ broker drops the 
> connection due to Inactivity after 60 seconds
> -
>
> Key: PROTON-1253
> URL: https://issues.apache.org/jira/browse/PROTON-1253
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0, 0.13.0
> Environment: Linux yuriy-Aspire-E5-573G 4.2.0-18-generic #22-Ubuntu 
> SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Yuriy Yakubskiy
>  Labels: messenger, patch, php-proton
> Attachments: 
> qpid-proton-0.13.0_messenger_set_idle_timeout_patch.tar.gz
>
>
> Dear developers,
> Could you please, clarify the following issue.
> PHP client disconnected after no data message in the queue for 60 seconds.
> Have client frame trace enabled (PN_TRACE_FRM=true)
> No active frame sent by the client in order to prevent being disconnected by 
> ActiveMQ InactivityMonitor
> Please advice, is there any way of setting heartbeats for the PHP client. 
> Please find, frames trace below.
> Kind Regards,
> Yuriy
> 2016-07-11 14:05:46
> [0x2af58f0]:  -> AMQP
> [0x2af58f0]:0 -> @open(16) 
> [container-id="68426F2E-012E-4A64-BE2E-1E5355B4B022", hostname="0.0.0.0", 
> channel-max=32767]
> [0x2af58f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x2af58f0]:0 -> @attach(18) [name="first-test-queue", handle=0, role=true, 
> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) 
> [address="first-test-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="first-test-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x2af58f0]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1024, 
> drain=false]
> [0x2af58f0]:  <- AMQP
> [0x2af58f0]:0 <- @open(16) [container-id="", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :platform="Java/1.7.0_101", 
> :"topic-prefix"="topic://", :"queue-prefix"="queue://", :version="5.12.0"}]
> [0x2af58f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x2af58f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0]
> [0x2af58f0]:0 <- @attach(18) [name="first-test-queue", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="first-test-queue"], target=@target(41) 
> [address="first-test-queue"], incomplete-unsettled=false, 
> initial-delivery-count=0]
> [0x2af58f0]:0 <- @close(24) [error=@error(29) 
> [condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout 
> expired"]]
> [0x2af58f0]:  <- EOS
> [0x2af58f0]:0 -> @close(24) []
> [0x2af58f0]:  -> EOS
> 2016-07-11 14:06:46



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

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

[jira] [Updated] (PROTON-782) pn_messenger_start always calls pn_messenger_resolve

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-782:
---
Fix Version/s: (was: 0.17.0)

> pn_messenger_start always calls pn_messenger_resolve
> 
>
> Key: PROTON-782
> URL: https://issues.apache.org/jira/browse/PROTON-782
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: David McCann
>  Labels: easyfix, messenger, patch
> Attachments: check_routes_only_when_specified.patch
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Code was added to pn_messenger_start in 0.8 to allow a resolve to take place 
> immediately if PN_FLAGS_CHECK_ROUTES is set.
> Unfortunately the check for the flag is incorrect, causing the resolve to 
> always take place.



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

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

[jira] [Updated] (PROTON-761) 100% CPU with multiple subscriptions

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-761:
---
Fix Version/s: (was: 0.17.0)

> 100% CPU with multiple subscriptions
> 
>
> Key: PROTON-761
> URL: https://issues.apache.org/jira/browse/PROTON-761
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Fabien CHEVALIER
>  Labels: messenger, reproducer
> Attachments: infinite-loop.c
>
>
> Calling pn_messenger_subscribe() twice (which seems to be perfectly valid) 
> can result in proton hanging at 100% cpu, when one of the two sources is 
> unreachable.
> To reproduce, start the attached test case against a pristine ActiveMQ copy 
> (./bin/activemq console). Proton will go nuts when trying to connect to the 
> unavailable amqp://localhost:15672/ganymede instance.



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

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

[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-252:
---
Fix Version/s: (was: 0.17.0)

> Reduce visibiliy of constructors for classes that should be created by 
> factories eg MessageImpl
> ---
>
> Key: PROTON-252
> URL: https://issues.apache.org/jira/browse/PROTON-252
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.4
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>Priority: Minor
>  Labels: api, close-pending
>
> These constructors are currently public but deprecated, and should be made 
> package-private where possible to enforce the use of the factories instead.



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

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

[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-158:
---
Fix Version/s: (was: 0.17.0)

> detach with invalid handle causes segfault
> --
>
> Key: PROTON-158
> URL: https://issues.apache.org/jira/browse/PROTON-158
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.2
>Reporter: Gordon Sim
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: close-pending, crash
>
> I.e. a detach where the handle was not previously used in an attach



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

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

[jira] [Updated] (PROTON-970) SASL options for setting path and name should not be transport-specific

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-970:
---
Fix Version/s: (was: 0.16.0)

> SASL options for setting path and name should not be transport-specific
> ---
>
> Key: PROTON-970
> URL: https://issues.apache.org/jira/browse/PROTON-970
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ted Ross
>  Labels: close-pending
>
> Both pn_sasl_config_name and pn_sasl_config_path take a pn_sasl_t object as 
> an argument, suggesting that different transports may use different 
> configurations.
> Cyrus SASL treats both the path and (server) name as per-process settings.
> The above methods in pn_sasl should reflect this scope and not use a 
> pn_sasl_t as an argument.



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

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

[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-287:
---
Fix Version/s: (was: 0.17.0)

> Fix Qpid Proton-C build with MinGW on Fedora
> 
>
> Key: PROTON-287
> URL: https://issues.apache.org/jira/browse/PROTON-287
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.4
> Environment: mingw32-gcc-4.7.2-7.fc18.x86_64
>Reporter: Robin Lee
>Assignee: Cliff Jansen
>  Labels: build, close-pending, patch
>
> This is my first submit on ASF JIRA.
> Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided:
> Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff
> Description: %z format specifier is not provided by MSVCRT, use MinGW version 
> of *printf to get it. Otherwise build failed with: 
> "proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 
> 'z' in format [-Werror=format]"
> Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff
> Description: Libraries and header files should be written in small cases, 
> otherwise build failed in cross build environment of Unix-like platforms: 
> "proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file 
> or directory"
> Patch 3: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff
> Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, 
> since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build 
> failed with: "proton-c/src/windows/driver.c:785:11: error: comparison between 
> signed and unsigned integer expressions [-Werror=sign-compare]"
> Patch 4: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff
> Description: Commented unimplemented functions. Otherwise build failed with 
> "proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 
> 'static' but never defined [-Werror=unused-function]"
> Patch 5: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff
> Description:
> 1. ID is not used, build failed with "../wincompat/internal/getopt.c:43:20: 
> error: 'ID' defined but not used [-Werror=unused-variable]"
> 2. Corrected getopt signiture, otherwise build failed with 
> "proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' 
> but argument is of type 'const char *'"
> 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so 
> #include wincompat/getopt.h in .c files instead of .h, otherwise build failed 
> with multiple definitions.
> Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff
> Description: WIN32 macro is not defined with -std=c99 but defined with 
> -std=gnu99. Use _WIN32 macro in all places.
> Built on Fedora and examples of recv and send are tested on Windows 7.



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

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

[jira] [Updated] (PROTON-1057) Windows SChannel SSL test failure

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1057:

Fix Version/s: Future

> Windows SChannel SSL test failure
> -
>
> Key: PROTON-1057
> URL: https://issues.apache.org/jira/browse/PROTON-1057
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.12.0
> Environment: Windows only.
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>  Labels: windows
> Fix For: Future
>
>
> This problem started since PROTON-1048 which did not touch the Proton-C 
> SChannel related code - it just tweaked the test infrastructure to use 
> alternate certificate formats for Windows.
> The proton_tests.ssl.SslTest.test_server_hostname_authentication test 
> randomly crashes on Windows, presumably from some memory corruption 
> somewhere.  It often runs fine.  Seems to happen more frequently on some 
> systems than others.  Not yet seen on a 64 bit build.



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

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

[jira] [Updated] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-824:
---
Assignee: Cliff Jansen

> Windows fails testIdleTimeout with assert p.conn.remote_condition
> -
>
> Key: PROTON-824
> URL: https://issues.apache.org/jira/browse/PROTON-824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Windows Server 2008 or 2012
> Visual studio 2010, x86
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>  Labels: close-pending, test-failure, windows
>
> {noformat}
> 1: proton_tests.engine.ServerTest.testIdleTimeout . 
> fail
> 1: Error during test:  Traceback (most recent call last):
> 1: File "D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test", 
> line 355, in run
> 1:   phase()
> 1: File 
> "D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py", 
> line 1919 (or so), in testIdleTimeout
> 1:   assert p.conn.remote_condition
> 1:   AssertionError
> {noformat}
> Playing with Program explicit timeout (trying 10 instead of 3) gets the test 
> to pass sometimes. It passes sometimes with 3 as well but normally fails.
> In debugging this it looks like there as no synchronization between what a 
> test will show through print statements and what the proton library shows 
> through PN_TRACE_FRM statements. Are there any hints to lining these up?



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

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

[jira] [Updated] (PROTON-840) Fix Windows components to use transport logging

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-840:
---
Fix Version/s: 0.17.0

> Fix Windows components to use transport logging
> ---
>
> Key: PROTON-840
> URL: https://issues.apache.org/jira/browse/PROTON-840
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8, 0.9
> Environment: Windows
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>  Labels: windows
> Fix For: 0.17.0
>
>
> Posix implemented new centralized logging.  Windows needs to catch up.



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

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

[jira] [Updated] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-824:
---
Labels: test-failure windows  (was: windows)

> Windows fails testIdleTimeout with assert p.conn.remote_condition
> -
>
> Key: PROTON-824
> URL: https://issues.apache.org/jira/browse/PROTON-824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Windows Server 2008 or 2012
> Visual studio 2010, x86
>Reporter: Chuck Rolke
>  Labels: close-pending, test-failure, windows
>
> {noformat}
> 1: proton_tests.engine.ServerTest.testIdleTimeout . 
> fail
> 1: Error during test:  Traceback (most recent call last):
> 1: File "D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test", 
> line 355, in run
> 1:   phase()
> 1: File 
> "D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py", 
> line 1919 (or so), in testIdleTimeout
> 1:   assert p.conn.remote_condition
> 1:   AssertionError
> {noformat}
> Playing with Program explicit timeout (trying 10 instead of 3) gets the test 
> to pass sometimes. It passes sometimes with 3 as well but normally fails.
> In debugging this it looks like there as no synchronization between what a 
> test will show through print statements and what the proton library shows 
> through PN_TRACE_FRM statements. Are there any hints to lining these up?



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

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

[jira] [Updated] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-824:
---
Labels: close-pending test-failure windows  (was: test-failure windows)

> Windows fails testIdleTimeout with assert p.conn.remote_condition
> -
>
> Key: PROTON-824
> URL: https://issues.apache.org/jira/browse/PROTON-824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Windows Server 2008 or 2012
> Visual studio 2010, x86
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>  Labels: close-pending, test-failure, windows
>
> {noformat}
> 1: proton_tests.engine.ServerTest.testIdleTimeout . 
> fail
> 1: Error during test:  Traceback (most recent call last):
> 1: File "D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test", 
> line 355, in run
> 1:   phase()
> 1: File 
> "D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py", 
> line 1919 (or so), in testIdleTimeout
> 1:   assert p.conn.remote_condition
> 1:   AssertionError
> {noformat}
> Playing with Program explicit timeout (trying 10 instead of 3) gets the test 
> to pass sometimes. It passes sometimes with 3 as well but normally fails.
> In debugging this it looks like there as no synchronization between what a 
> test will show through print statements and what the proton library shows 
> through PN_TRACE_FRM statements. Are there any hints to lining these up?



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

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

[jira] [Updated] (PROTON-789) Lots of Deprecation Warnings on OSX

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-789:
---
Labels: close-pending osx  (was: osx)

> Lots of Deprecation Warnings on OSX
> ---
>
> Key: PROTON-789
> URL: https://issues.apache.org/jira/browse/PROTON-789
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
> Environment: Darwin gethsemane.local 14.0.0 Darwin Kernel Version 
> 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 
> x86_64
>Reporter: Weston M. Price
>Priority: Minor
>  Labels: close-pending, osx
> Attachments: proton-build-osx.txt
>
>
> Building proton-c on OS X 10.10.1 (Yosemite) gives quite a few deprecation 
> warnings, primarily in the SSL libraries. I have attached a file showing a 
> typical build run. 



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

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

[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-766:
---
Assignee: Cliff Jansen

> Proton-c Windows IO prints misleading error messages
> 
>
> Key: PROTON-766
> URL: https://issues.apache.org/jira/browse/PROTON-766
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
> Environment: Windows Server 2012 R2
> Examples messaging c recv
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>  Labels: windows
> Fix For: 0.17.0
>
>
> Connecting to a port that is not open.
> Windows:
> {noformat}
> > send -a [::1]
> recv: No error
> [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch: 
> ''
> CONNECTION ERROR connection aborted (remote)
> send: No error
> {noformat}
> The same action on Linux:
> {noformat}
> > ./send -a [::1]
> recv: Connection refused
> [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch: 
> Insufficient data to determine protocol [''] (connection aborted)
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> {noformat}
> The Linux messages are more useful and indicate the precise error conditions. 
> The Windows messages show recv: and send: with 'No error' and that is not the 
> case. 
> The same error message is displayed for IPv4 and IPv6.



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

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

[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-766:
---
Fix Version/s: 0.17.0

> Proton-c Windows IO prints misleading error messages
> 
>
> Key: PROTON-766
> URL: https://issues.apache.org/jira/browse/PROTON-766
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
> Environment: Windows Server 2012 R2
> Examples messaging c recv
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>  Labels: windows
> Fix For: 0.17.0
>
>
> Connecting to a port that is not open.
> Windows:
> {noformat}
> > send -a [::1]
> recv: No error
> [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch: 
> ''
> CONNECTION ERROR connection aborted (remote)
> send: No error
> {noformat}
> The same action on Linux:
> {noformat}
> > ./send -a [::1]
> recv: Connection refused
> [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch: 
> Insufficient data to determine protocol [''] (connection aborted)
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> {noformat}
> The Linux messages are more useful and indicate the precise error conditions. 
> The Windows messages show recv: and send: with 'No error' and that is not the 
> case. 
> The same error message is displayed for IPv4 and IPv6.



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

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

[jira] [Updated] (PROTON-151) Have the python interface use dynamic proxies to the engine impl objects so to ensure that only public interface methods are being used by the python tests.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-151:
---
Fix Version/s: Future

> Have the python interface use dynamic proxies to the engine impl objects so 
> to ensure that only public interface methods are being used by the python 
> tests.
> 
>
> Key: PROTON-151
> URL: https://issues.apache.org/jira/browse/PROTON-151
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Reporter: Hiram Chirino
>  Labels: patch, testing
> Fix For: Future
>
> Attachments: PROTON-151.patch
>
>




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

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

[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-186:
---
Labels: close-pending patch  (was: patch)

> Message encode should always return the number of bytes needed to fully 
> encode the message
> --
>
> Key: PROTON-186
> URL: https://issues.apache.org/jira/browse/PROTON-186
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, proton-j
>Reporter: Hiram Chirino
>  Labels: close-pending, patch
> Attachments: PROTON-186v2.patch
>
>




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

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

[jira] [Updated] (PROTON-391) Proton perl binding fails to build on OS X

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-391:
---
Fix Version/s: Future

> Proton perl binding fails to build on OS X
> --
>
> Key: PROTON-391
> URL: https://issues.apache.org/jira/browse/PROTON-391
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: perl-binding
> Environment: OS X
>Reporter: Hiram Chirino
>  Labels: osx
> Fix For: Future
>
>
> [ 71%] Building C object 
> proton-c/bindings/perl/CMakeFiles/cproton_perl.dir/perlPERL_wrap.c.o
> In file included from 
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:26,
>  from 
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31,
>  from 
> /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574:
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:53: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_equals’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:65: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_list_remove’
> In file included from 
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31,
>  from 
> /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574:
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:73: error: 
> expected specifier-qualifier-list before ‘bool’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:111: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_next’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:112: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_prev’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:113: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_enter’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:114: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_exit’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:115: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_lookup’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:126: 
> error: expected declaration specifiers or ‘...’ before ‘bool’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:129: 
> error: expected declaration specifiers or ‘...’ before ‘bool’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:154: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_is_array_described’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:156: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_is_described’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:157: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_is_null’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:158: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_get_bool’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:187: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_data_restore’
> In file included from 
> /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574:
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:428: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_transport_quiesced’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:445: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_link_is_sender’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:446: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_link_is_receiver’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:455: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_link_advance’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:500: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_terminus_is_dynamic’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:501: 
> error: expected declaration specifiers or ‘...’ before ‘bool’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:519: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_delivery_settled’
> /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:521: 
> error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘pn_delivery_partial’
> 

[jira] [Updated] (PROTON-390) Suppress or Fix the warnings openssl.c produce

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-390:
---
Fix Version/s: Future

> Suppress or Fix the warnings openssl.c produce
> --
>
> Key: PROTON-390
> URL: https://issues.apache.org/jira/browse/PROTON-390
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
> Environment: OS X
>Reporter: Hiram Chirino
>  Labels: osx
> Fix For: Future
>
>
> openssl.c produces lots of warnings.
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘_log_ssl_error’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:165: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:167: warning: 
> ‘ERR_error_string_n’ is deprecated (declared at 
> /usr/include/openssl/err.h:280)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:169: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘ssl_failed’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:189: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:191: warning: 
> ‘ERR_error_string_n’ is deprecated (declared at 
> /usr/include/openssl/err.h:280)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘verify_callback’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:257: warning: 
> ‘X509_STORE_CTX_get_error_depth’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:453)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:261: warning: 
> ‘X509_STORE_CTX_get_current_cert’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:454)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: 
> ‘X509_STORE_CTX_get_ex_data’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:450)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: 
> ‘SSL_get_ex_data_X509_STORE_CTX_idx’ is deprecated (declared at 
> /usr/include/openssl/ssl.h:1601)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:268: warning: 
> ‘SSL_get_ex_data’ is deprecated (declared at /usr/include/openssl/ssl.h:1587)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:285: warning: 
> ‘X509_get_ext_d2i’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1151)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:287: warning: 
> ‘sk_num’ is deprecated (declared at /usr/include/openssl/stack.h:81)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:290: warning: 
> ‘sk_value’ is deprecated (declared at /usr/include/openssl/stack.h:82)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:295: warning: 
> ‘ASN1_STRING_to_UTF8’ is deprecated (declared at 
> /usr/include/openssl/asn1.h:981)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:299: warning: 
> ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:308: warning: 
> ‘X509_get_subject_name’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1013)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:310: warning: 
> ‘X509_NAME_get_index_by_NID’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1105)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:311: warning: 
> ‘X509_NAME_get_entry’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1108)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:312: warning: 
> ‘X509_NAME_ENTRY_get_data’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1130)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:315: warning: 
> ‘ASN1_STRING_to_UTF8’ is deprecated (declared at 
> /usr/include/openssl/asn1.h:981)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:319: warning: 
> ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:329: warning: 
> ‘X509_STORE_CTX_set_error’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:452)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘get_dh2048’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:371: warning: 
> ‘DH_new’ is deprecated (declared at /usr/include/openssl/dh.h:184)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:372: warning: 
> ‘BN_bin2bn’ is deprecated (declared at 

[jira] [Updated] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-21:
--
Fix Version/s: 0.17.0

> Extract the logical AMQP frame handling to an AbstractConnectionHandler
> ---
>
> Key: PROTON-21
> URL: https://issues.apache.org/jira/browse/PROTON-21
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, proton-j
>Reporter: Hiram Chirino
>Assignee: Rob Godfrey
>  Labels: api, patch
> Fix For: 0.17.0
>
> Attachments: PROTON-21-v3.patch
>
>
> Right now all the logic that handles logical AMQP frame events is inside of 
> the TransportImpl class.  That interface only allows you to pump bytes in and 
> out of the connection.  If we extract all the handling logic to an 
> AbstractConnectionHandler you should be able to use that directly and pump 
> logical AMQP frames and avoid the frame encoding/decoding phase that the 
> TransportImpl also does.



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

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

[jira] [Updated] (PROTON-598) CProton python binding fails to build Windows debug configuration

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-598:
---
Labels: close-pending windows  (was: windows)

> CProton python binding fails to build Windows debug configuration
> -
>
> Key: PROTON-598
> URL: https://issues.apache.org/jira/browse/PROTON-598
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.7
> Environment: Windows,  Python 2.6.1
>Reporter: Chuck Rolke
>  Labels: close-pending, windows
>
> cpython fails to link with file python26_d.lib not found.
> The issue here is that the windows installer for python does not install the 
> debug versions (identified by the _d suffix) of the python libraries. Wisdom 
> from the web suggests either to build your own debug python or to debug using 
> a release build.
> Links using the RelWithDebInfo work just fine and I can make progress running 
> ctest. Just a heads up for anyone who wants to run ctest with Debug builds.



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

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

[jira] [Updated] (PROTON-599) Visual Studio warnings - enumeration update

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-599:
---
Labels: close-pending windows  (was: windows)

> Visual Studio warnings - enumeration update
> ---
>
> Key: PROTON-599
> URL: https://issues.apache.org/jira/browse/PROTON-599
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.7
> Environment: Visual Studio 2008, 2010, 2012, 2013
>Reporter: Chuck Rolke
>  Labels: close-pending, windows
> Attachments: vs-proton-warnings.txt
>
>
> After suppressing the 'usual' warnings (see PROTON-546, 
> http://svn.apache.org/r1601010) and running some later compiler versions a 
> new list of errors emerges. Please see attached listing for details.



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

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

[jira] [Updated] (PROTON-546) C++ Windows warnings: conversions and possible loss of data

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-546:
---
Fix Version/s: 0.17.0

> C++ Windows warnings: conversions and possible loss of data
> ---
>
> Key: PROTON-546
> URL: https://issues.apache.org/jira/browse/PROTON-546
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Chuck Rolke
>Assignee: Andrew Stitcher
>  Labels: windows
> Fix For: 0.17.0
>
> Attachments: PROTON-546-size-warnings.txt
>
>
> Windows has other warnings similar to PROTON-545, especially during 64-bit 
> builds.
> See attached file for details.



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

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

[jira] [Updated] (PROTON-409) [proton-c] Windows .dll does not have embedded version resource

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-409:
---
Labels: close-pending windows  (was: windows)

> [proton-c] Windows .dll does not have embedded version resource 
> 
>
> Key: PROTON-409
> URL: https://issues.apache.org/jira/browse/PROTON-409
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.4
> Environment: Windows
>Reporter: Chuck Rolke
>  Labels: close-pending, windows
>
> Windows output objects may contain a version resource that allow the build 
> engineer to tag files with file and product resource numbers. Support for 
> this feature is missing.



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

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

[jira] [Updated] (PROTON-407) [proton-c] Windows install does not install .lib nor .pdb files

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-407:
---
Labels: close-pending windows  (was: windows)

> [proton-c] Windows install does not install .lib nor .pdb files
> ---
>
> Key: PROTON-407
> URL: https://issues.apache.org/jira/browse/PROTON-407
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.4
> Environment: Windows 
>Reporter: Chuck Rolke
>  Labels: close-pending, windows
>
> In current trunk building the INSTALL project in VS2010 does not place the 
> qpid-proton.lib, qpid-proton.pdb files into the install area. Consequently 
> consumers using an installed kit are unable to link to the qpid-proton 
> library.
> In a dev environment the files are available in the build area as expected.



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

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

[jira] [Updated] (PROTON-363) recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error 11004

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-363:
---
Labels: close-pending windows  (was: windows)

> recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error 
> 11004
> -
>
> Key: PROTON-363
> URL: https://issues.apache.org/jira/browse/PROTON-363
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.5
> Environment: Windows XP, Visual Studio 2010
>Reporter: Jakub Scholz
>  Labels: close-pending, windows
>
> I build the proton-c library on Windows XP using Visual Studio 10. 
> Afterwards, when trying to run the recv.exe and send.exe examples, the 
> recv.exe always fails with:
> > recv.exe amqp://~0.0.0.0:5672
> getnameinfo: The requested name is valid and was found in the database, but 
> it does not have the correct associated data being resolved for.
> It doesn't fail immediately after start but only when I attempt to connect 
> with send.exe. As a result, the Proton seems to be pretty much not working on 
> my machine.
> ---
> The error seems to originate from the function pn_listener_accept in driver.c 
> and it translates to WSANO_DATA error / error 11004. I did some digging 
> around and playing with the getnameinfo function and it seems to me, that the 
> problem is that the getnameinfo function is unable to recognize the service 
> name based on the port number. And - according to MSDN 
> (http://msdn.microsoft.com/en-us/library/windows/desktop/ms738532(v=vs.85).aspx)
>  - that on Windows Server 2003 and earlier results in error (on Windows Vista 
> and later this works fine).
> If I add a flag NI_NUMERICSERV to the getnameinfo call: 
> code = getnameinfo((struct sockaddr *) , addrlen, host, 1024, serv, 64, 
> NI_NUMERICSERV)
> it will not return an error but return success and use the port number as a 
> service name. And with this change the recv.exe starts working fine.
> However, adding this flag will on Windows Vista and higher and in Linux 
> probably result in the service name being always returned as a port number 
> and not as a name. So I'm not sure it is desired to add this flag on all 
> platforms. 
> Regards
> Jakub



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

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

[jira] [Updated] (PROTON-237) Porting Issue -- basename() not found in Visual Studio 2010

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-237:
---
Labels: build close-pending windows  (was: build windows)

> Porting Issue -- basename() not found in Visual Studio 2010
> ---
>
> Key: PROTON-237
> URL: https://issues.apache.org/jira/browse/PROTON-237
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
> Environment: Windows Visual Studio 2010
>Reporter: Mary hinton
>  Labels: build, close-pending, windows
>
> The basename() function in proton.c is not found in Visual Studio 2010. It is 
> in Visual Studio 2012 when the  header is included.
> It is only used in a printf statement and is not needed for porting to Visual 
> Studio 2010:
> printf("Usage: %s [-h] [-c [user[:password]@]host[:port]] [-a ] [-m 
> ]\n", basename(argv[0])); 



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

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

[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-236:
---
Labels: close-pending windows  (was: windows)

> Porting Issue -- Visual Studio does not provide a getopt() function
> ---
>
> Key: PROTON-236
> URL: https://issues.apache.org/jira/browse/PROTON-236
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
>Assignee: Cliff Jansen
>  Labels: close-pending, windows
> Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h
>
>
> Since Visual Studio 2010 does not provide a getopt(), I used the getopt() 
> function found in the GNU library getopt.h and getopt.c. I made a few minor 
> changes and will attach these files to this JIRA.
> Besides the proton.c file, the proton project workspace for Visual Studio 
> would need to include getopt() files.



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

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

[jira] [Updated] (PROTON-239) Porting Issue -- gethostname() is part of winsock library

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-239:
---
Labels: build close-pending windows  (was: build windows)

> Porting Issue -- gethostname() is part of winsock library
> -
>
> Key: PROTON-239
> URL: https://issues.apache.org/jira/browse/PROTON-239
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
>Assignee: Cliff Jansen
>  Labels: build, close-pending, windows
>
> In Visual Studio, gethostname() is found within the winsock library. To use 
> it in proton.c, we have to include the winsock header and make sure the 
> WSAStartup() (used to initialize the windows socket library) has already been 
> called by pn_driver(). 
> I was wondering if we could isolate the winsock header so that it is only 
> included in driver.c.
> We could set up a new function in driver.c called pn_gethostname() whose only 
> function is to call gethostname().
> int pn_gethostname(char *name, int namelen)
> {
>   return gethostname(name, namelen);
> }



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

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

[jira] [Updated] (PROTON-515) Port to OpenVMS

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-515:
---
Fix Version/s: 0.17.0

> Port to OpenVMS
> ---
>
> Key: PROTON-515
> URL: https://issues.apache.org/jira/browse/PROTON-515
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.11.1
> Environment: OpenVMS
>Reporter: Tomas Soltys
>Assignee: Andrew Stitcher
>  Labels: openvms, patch
> Fix For: 0.17.0
>
> Attachments: 
> 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, 
> CMakeLists.txt.patch, io.c.patch, pipe.c.patch
>
>
> There is a need for proton-c port to OpenVMS platform.
> To make proton-c functional on OpenVMS few changes in the source code are 
> required.
> Here is list of files I have identified which require some attention:
> proton-c/src/platform_fmt.h
> proton-c/src/posix/driver.c
> proton-c/src/object/object.c
> proton-c/src/codec/codec.c



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

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

[jira] [Updated] (PROTON-515) Port to OpenVMS

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-515:
---
Labels: openvms patch  (was: OpenVMS patch)

> Port to OpenVMS
> ---
>
> Key: PROTON-515
> URL: https://issues.apache.org/jira/browse/PROTON-515
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.11.1
> Environment: OpenVMS
>Reporter: Tomas Soltys
>Assignee: Andrew Stitcher
>  Labels: openvms, patch
> Fix For: 0.17.0
>
> Attachments: 
> 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, 
> CMakeLists.txt.patch, io.c.patch, pipe.c.patch
>
>
> There is a need for proton-c port to OpenVMS platform.
> To make proton-c functional on OpenVMS few changes in the source code are 
> required.
> Here is list of files I have identified which require some attention:
> proton-c/src/platform_fmt.h
> proton-c/src/posix/driver.c
> proton-c/src/object/object.c
> proton-c/src/codec/codec.c



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

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

[jira] [Updated] (PROTON-1021) ProtonE - the Deeply Embedded ProtonC variant

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1021:

Labels: features patch  (was: features)

> ProtonE - the Deeply Embedded ProtonC variant
> -
>
> Key: PROTON-1021
> URL: https://issues.apache.org/jira/browse/PROTON-1021
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
> Environment: Embedded C - IAR or GCC.
>Reporter: German Shepherd (PrE)
>Priority: Minor
>  Labels: features, patch
> Fix For: Future
>
>
> Let me introduce a project I've started on 2013, when I've been tasked with a 
> solution on how to connect an deeply embedded Wi-Fi enabled device to MS 
> Azure Cloud (the plan is to connect millions of such devices).
> The obvious solution was to go with ServiceBus and AMQP over TLS. Since the 
> embedded stuff is always written in plain C, the ProtonC is choice was 
> obvious.
> The Proton-C typically requires a 230kB of RAM by default (most of it 
> dynamically allocated), which is way too much of what is physically available 
> in any embedded CPU of the general class (those typically end up with RAM 
> sizes in 192kB area) - so there is no way on how to directly use the ProtonC 
> on such CPUs.
> *Solution?*
> The outcome of my work is the *Proton-E*, based off the Proton-C library, 
> squeezed to run on 32kB of total RAM usage (without sacrificing any 
> functionality) and with a TLS on side taking addition approx. 11kB.
> This allows you to fit the AMQPS into any connected embedded CPU with 128kB 
> of RAM (or more) - which most of the commonly available CPUs on market 
> provide (for a great price).
> The "embedded" modifications are backwards applicable to the ProtonC, and 
> this is what I would like to introduce through this JIRA Ticket.
> *Note*
> This work was picked up by Microsoft in mid-2014, and I have personally 
> cooperated with them; but I have not seen any result being provided to 
> community, as it seems the whole effort on their side vanished (and if not, 
> they stopped the cooperation - so they won't have my latest sources).
> Never mind, as I have the most actual source code (as I've never stopped the 
> development, and I do follow every commit the ProtonC community does), none 
> is lost.
> At this moment, before the ProtonE source gets out, let me use this ticket to 
> provide an assurance, that indeed the ProtonE (resp. modified ProtonC) can be 
> used on the constrained system, and, most importantly, it is production ready 
> for Azure Cloud.
> *ProtonE Features*
> * Super-Low RAM footprint: total 32kB of RAM usage, for a AMQP message with 
> 1.5kB of payload
> * Azure Cloud: Service Bus / eventHub - both verified (IoT Hub - very close 
> future, will definitely work - my colleagues cooperate with MS on this)
> * Azure Cloud: SASL PLAIN over TLS (Active Directory) - verified
> * Azure Cloud: SAS tokens (CBS) - verified
> * No modifications to ProtonC API what-so-ever
> * TCP stack, and RTOS, independent
> *The ProtonE has been made to run and personally tested, by myself, with the 
> following setup: *
> * CPUs: 32-bit ARM - Cortex M3 (STM32, SAM3), Cortex M4 (Atmel SAM4), Cortex 
> M7 (Atmel SAM S70/V71), I also run this on TI Sitara with embedded RTOS
> * There is no reason why this would not work on any other CPUs (all is just a 
> plain-C code)
> * RTOS: FreeRTOS/SafeRTOS; but primarily: expressLogic ThreadX
> * TCP/IP stack: expressLogic NetX & NetX-Duo TCP/IP
> * Comms: Broadcom WICED Wi-Fi solution
> * TLS via Mocana NanoSSL (v6.0 or newer)
> * TLS via MatrixSSL (3.6.1 or newer)
> *SSL/TLS*
> This is quite a huge memory hog, but should you understand it deeply, you 
> won't have trouble managing this.
> Some numbers I've got:
> * Handshake establishment: RAM usage peak is 30kB for TLS itself (handshake: 
> RSA)
> * After the Handshake is done and the TLS tunnel is open: the TLS itself 
> requires 11kB of RAM (tunnel: AES)
> I'm looking forward to have Microsoft to switch the Azure solely to ECC for 
> us (now they have RSA and ECC, and the server-side cert is solely RSA). Then 
> the handshake number will be even much more positive.
> *Final words*
> Once you realize that the AMQPS is the only possible scalable future for the 
> IoT (... hate this buzzword, BTW.), where the 95% of devices will be deeply 
> embedded ones, then it is obvious what role the ProtonE will play.
> Best regards from CZ,
>  Adam N



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

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

[jira] [Updated] (PROTON-1021) ProtonE - the Deeply Embedded ProtonC variant

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1021:

Fix Version/s: Future

> ProtonE - the Deeply Embedded ProtonC variant
> -
>
> Key: PROTON-1021
> URL: https://issues.apache.org/jira/browse/PROTON-1021
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
> Environment: Embedded C - IAR or GCC.
>Reporter: German Shepherd (PrE)
>Priority: Minor
>  Labels: features
> Fix For: Future
>
>
> Let me introduce a project I've started on 2013, when I've been tasked with a 
> solution on how to connect an deeply embedded Wi-Fi enabled device to MS 
> Azure Cloud (the plan is to connect millions of such devices).
> The obvious solution was to go with ServiceBus and AMQP over TLS. Since the 
> embedded stuff is always written in plain C, the ProtonC is choice was 
> obvious.
> The Proton-C typically requires a 230kB of RAM by default (most of it 
> dynamically allocated), which is way too much of what is physically available 
> in any embedded CPU of the general class (those typically end up with RAM 
> sizes in 192kB area) - so there is no way on how to directly use the ProtonC 
> on such CPUs.
> *Solution?*
> The outcome of my work is the *Proton-E*, based off the Proton-C library, 
> squeezed to run on 32kB of total RAM usage (without sacrificing any 
> functionality) and with a TLS on side taking addition approx. 11kB.
> This allows you to fit the AMQPS into any connected embedded CPU with 128kB 
> of RAM (or more) - which most of the commonly available CPUs on market 
> provide (for a great price).
> The "embedded" modifications are backwards applicable to the ProtonC, and 
> this is what I would like to introduce through this JIRA Ticket.
> *Note*
> This work was picked up by Microsoft in mid-2014, and I have personally 
> cooperated with them; but I have not seen any result being provided to 
> community, as it seems the whole effort on their side vanished (and if not, 
> they stopped the cooperation - so they won't have my latest sources).
> Never mind, as I have the most actual source code (as I've never stopped the 
> development, and I do follow every commit the ProtonC community does), none 
> is lost.
> At this moment, before the ProtonE source gets out, let me use this ticket to 
> provide an assurance, that indeed the ProtonE (resp. modified ProtonC) can be 
> used on the constrained system, and, most importantly, it is production ready 
> for Azure Cloud.
> *ProtonE Features*
> * Super-Low RAM footprint: total 32kB of RAM usage, for a AMQP message with 
> 1.5kB of payload
> * Azure Cloud: Service Bus / eventHub - both verified (IoT Hub - very close 
> future, will definitely work - my colleagues cooperate with MS on this)
> * Azure Cloud: SASL PLAIN over TLS (Active Directory) - verified
> * Azure Cloud: SAS tokens (CBS) - verified
> * No modifications to ProtonC API what-so-ever
> * TCP stack, and RTOS, independent
> *The ProtonE has been made to run and personally tested, by myself, with the 
> following setup: *
> * CPUs: 32-bit ARM - Cortex M3 (STM32, SAM3), Cortex M4 (Atmel SAM4), Cortex 
> M7 (Atmel SAM S70/V71), I also run this on TI Sitara with embedded RTOS
> * There is no reason why this would not work on any other CPUs (all is just a 
> plain-C code)
> * RTOS: FreeRTOS/SafeRTOS; but primarily: expressLogic ThreadX
> * TCP/IP stack: expressLogic NetX & NetX-Duo TCP/IP
> * Comms: Broadcom WICED Wi-Fi solution
> * TLS via Mocana NanoSSL (v6.0 or newer)
> * TLS via MatrixSSL (3.6.1 or newer)
> *SSL/TLS*
> This is quite a huge memory hog, but should you understand it deeply, you 
> won't have trouble managing this.
> Some numbers I've got:
> * Handshake establishment: RAM usage peak is 30kB for TLS itself (handshake: 
> RSA)
> * After the Handshake is done and the TLS tunnel is open: the TLS itself 
> requires 11kB of RAM (tunnel: AES)
> I'm looking forward to have Microsoft to switch the Azure solely to ECC for 
> us (now they have RSA and ECC, and the server-side cert is solely RSA). Then 
> the handshake number will be even much more positive.
> *Final words*
> Once you realize that the AMQPS is the only possible scalable future for the 
> IoT (... hate this buzzword, BTW.), where the 95% of devices will be deeply 
> embedded ones, then it is obvious what role the ProtonE will play.
> Best regards from CZ,
>  Adam N



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

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

[jira] [Updated] (PROTON-905) Long-lived connections leak sessions and links

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-905:
---
Fix Version/s: 0.17.0

> Long-lived connections leak sessions and links
> --
>
> Key: PROTON-905
> URL: https://issues.apache.org/jira/browse/PROTON-905
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9.1, 0.10
>Reporter: Ken Giusti
>  Labels: leak
> Fix For: 0.17.0
>
> Attachments: test-send.py
>
>
> I found this issue while debugging a crash dump of qpidd.
> Long lived connections do not free its sessions/link.
> This only applies when NOT using the event model.  The version of qpidd I 
> tested against (0.30) still uses the iterative model.  Point to consider, I 
> don't know why this is the case.
> Details:  I have a test script that opens a single connection, then 
> continually creates sessions/links over that connection, sending one message 
> before closing and freeing the sessions/links.  See attached.
> Over time the qpidd run time consumes all memory on the system and is killed 
> by OOM.  To be clear, I'm using drain to remove all sent messages - there is 
> no message build up.
> On debugging this, I'm finding thousands of session objects on the 
> connections free sessions weakref list.  Every one of those sessions has a 
> refcount of one.
> Once the connection is finalized, all session objects are freed.  But until 
> then, freed sessions continue to accumulate indefinitely.



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

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

[jira] [Updated] (PROTON-703) inlining performance improvements

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-703:
---
Labels: close-pending perf  (was: perf)

> inlining performance improvements
> -
>
> Key: PROTON-703
> URL: https://issues.apache.org/jira/browse/PROTON-703
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: michael goulish
>Assignee: michael goulish
>Priority: Minor
>  Labels: close-pending, perf
>
> omnibus jira for any other inlining performance improvements i may find.
> notes to self:
>   * don't affect public APIs.
>   * don't forget to test Debug build.



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

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

[jira] [Updated] (PROTON-659) if protons internal buffer gets large, performance can suffer

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-659:
---
Fix Version/s: 0.17.0

> if protons internal buffer gets large, performance can suffer
> -
>
> Key: PROTON-659
> URL: https://issues.apache.org/jira/browse/PROTON-659
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.7
>Reporter: Gordon Sim
>Priority: Minor
>  Labels: perf
> Fix For: 0.17.0
>
>
> In doing some performance investigations using qpid::messaging over 1.0, in 
> particular as message size got larger, I saw much lower throughput and lots 
> of cpu used. From callgrind it looked like this was from shuffliing up the 
> buffer in pn_dispatcher_output. Because of the threading in qpid::messaging, 
> it was possible for the application to generate too much output using the 
> top-half of the engine API before the IO was done for the bottom half. Fixing 
> that in qpid:messaging improved performance.
> There may perhaps be something that proton could do to make users more aware 
> of this (e.g. a log message if the buffer exceeds a certain size? or just 
> documentation?)



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

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

[jira] [Updated] (PROTON-621) Added support for Android to Qpid-Proton0.6

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-621:
---
Labels: android features patch  (was: features github-import patch)

> Added support for Android to Qpid-Proton0.6
> ---
>
> Key: PROTON-621
> URL: https://issues.apache.org/jira/browse/PROTON-621
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.6
> Environment: Android OS
>Reporter: Jimmy Campbell
>  Labels: android, features, patch
> Fix For: Future
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
>  The focus of this JIRA is for providing a method to build the Proton-C 
> library and get it running in the Android environment. I have forked the 
> Qpid-Proton repository and made a branch called AndroidProton that is based 
> off of 0.6. I have put together a little folder called proton-a which sits 
> inside the former 0.6 branch. Proton-a is the foundation for Proton on 
> Android. It contains a readme with instructions on how to build targeting 
> Android, the necessary files, and an example Android Project utilizing the 
> Proton-C library. I would like my changes to get pulled into the 0.6 branch 
> as an added feature.
> https://github.com/jimmypc92/qpid-proton/tree/AndroidProton
> Issues porting Proton-C to Android
> The first issue of getting Proton-C working on Android was the lack of 
> openssl and uuid support. I fixed this by using open source implementations I 
> found online. My openssl for Android implementation was acquired off an old 
> github repository 
> "https://github/eighthave/openssl-android.git;
> My uuid for Android implementation was acquired from AOSP
> "android/platform/external/e2fsprogs/./lib/uuid"
> Building the C libraries for Android
> I built these libraries using the ndk-build system that comes with the 
> Android ndk. My folder comes with a README that links to the Android ndk if 
> one does not already have it. The README folder also has step-by-step 
> instructions for someone to build the library their selves. As I said, this 
> involves calling ndk-build 3 times. The user will build the openssl, then the 
> uuid, then the Proton-C libraries. The user can create their own java 
> bindings for calling the c library from Android by building the desktop 
> Qpid-Proton-0.6 with java swig bindings. Or they can use the jars that come 
> with my folder.
> Changes
> Every occurrence of getprotobyname("tcp")->p_proto had to be replaced with 
> IPPROTO_TCP in the source file proton-c/src/posix/driver.c This fix checks if 
> the source is being compiled with the NDK compiler to ensure that it doesn't 
> break the desktop build. The pre-processor definition for Android is 
> #ifdef __ANDROID__
> functional bug fix
> The swig language binding jars produced with Qpid-Proton-0.6 build system 
> were causing a segfault whenever receiving a message that had the messageId 
> set to a generated uuid from the desktop Qpid-Proton-0.6 client. The error is 
> in JNIMessage.java in 
> qpid-proton-0.6/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/messsage/jni.
>  at the convert method whenever type is a uuid.
> The fix I used involved removing the use of pn_bytes_to_array in favor of 
> getting a pn_uuid_t from value (which is a pn_atom_t_u) and then getting the 
> byte array directly from the pn_uuid_t with the pn_uuid_t.getBytes() method 
> call.
> {code:title=JNIMessage.java|borderStyle=solid}
> else if(pn_type_t.PN_UUID.equals(type))
> {
>  pn_uuid_t uuidT = value.getAs_uuid();
>  byte[] uuidBytes = uuidT.getBytes();
>  -deleted- byte[] b = Proton.pn_bytes_to_array(value.getAs_bytes());
>  ByteBuffer buf = ByteBuffer.wrap(uuidBytes);
>  return new UUID(buf.getLong(), buf.getLong());
> }
> {code}
> Example Android project
> In the AndroidProtonBuild folder, a sample Android Proton project is included 
> that uses Proton-C. This project contains a file called UsingSwig.java which 
> exposes simple methods like send(). This sample project has a send and 
> receive button to check if the function is working with your target messaging 
> endpoint. The address to send and receive from must be specified in the 
> UsingSwig.java source file.
> tip for native development on android
> If you want to check for compilation by the NDK build system use
> #ifdef __ANDROID__
> If you want to use eclipse and print to LogCat from C code, include the 
> following lines at the top of the source file:
> #ifdef __ANDROID__
> #include 
> #define LOG_TAG   "my-log-tag"
> #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__)
> #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__)
> #endif
>  These lines allow you to call 

[jira] [Updated] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1073:

Fix Version/s: 0.12.0

> Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
> ---
>
> Key: PROTON-1073
> URL: https://issues.apache.org/jira/browse/PROTON-1073
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.0
> Environment: MacOS X 10.11.1, XCode 7.1.1
> Compilation options:
> env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake 
> .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF 
> -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64
>Reporter: Ollivier Robert
>Assignee: Cliff Jansen
>  Labels: build-failure, osx
> Fix For: 0.12.0
>
>
> Compiling 0.11 leads to build failure in the tests for the C++ bindings:
> [...]
> Linking CXX shared library libqpid-proton-cpp.dylib
> [ 66%] Built target qpid-proton-cpp
> Scanning dependencies of target conversion_test
> [ 66%] Building CXX object 
> proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p = s.ptr();
> ^   ~~~
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25:
>  note:
>   in instantiation of function template specialization
>   'test_owning   std::__1::default_delete >,
>   std::__1::unique_ptr std::__1::default_delete > >'
>   requested here
> failed += run_test(_owning<
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p2 = s.ptr();
> ^~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> 2 errors generated.
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o]
>  Error 1
> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error 
> 2
> make: *** [all] Error 2



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

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

[jira] [Closed] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1

[Justin Ross (JIRA)]

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

Justin Ross closed PROTON-1073.
---
Resolution: Fixed

> Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
> ---
>
> Key: PROTON-1073
> URL: https://issues.apache.org/jira/browse/PROTON-1073
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.0
> Environment: MacOS X 10.11.1, XCode 7.1.1
> Compilation options:
> env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake 
> .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF 
> -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64
>Reporter: Ollivier Robert
>Assignee: Cliff Jansen
>  Labels: build-failure, osx
> Fix For: 0.12.0
>
>
> Compiling 0.11 leads to build failure in the tests for the C++ bindings:
> [...]
> Linking CXX shared library libqpid-proton-cpp.dylib
> [ 66%] Built target qpid-proton-cpp
> Scanning dependencies of target conversion_test
> [ 66%] Building CXX object 
> proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p = s.ptr();
> ^   ~~~
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25:
>  note:
>   in instantiation of function template specialization
>   'test_owning   std::__1::default_delete >,
>   std::__1::unique_ptr std::__1::default_delete > >'
>   requested here
> failed += run_test(_owning<
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p2 = s.ptr();
> ^~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> 2 errors generated.
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o]
>  Error 1
> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error 
> 2
> make: *** [all] Error 2



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

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

[jira] [Updated] (PROTON-621) Added support for Android to Qpid-Proton0.6

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-621:
---
Fix Version/s: Future

> Added support for Android to Qpid-Proton0.6
> ---
>
> Key: PROTON-621
> URL: https://issues.apache.org/jira/browse/PROTON-621
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.6
> Environment: Android OS
>Reporter: Jimmy Campbell
>  Labels: android, features, patch
> Fix For: Future
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
>  The focus of this JIRA is for providing a method to build the Proton-C 
> library and get it running in the Android environment. I have forked the 
> Qpid-Proton repository and made a branch called AndroidProton that is based 
> off of 0.6. I have put together a little folder called proton-a which sits 
> inside the former 0.6 branch. Proton-a is the foundation for Proton on 
> Android. It contains a readme with instructions on how to build targeting 
> Android, the necessary files, and an example Android Project utilizing the 
> Proton-C library. I would like my changes to get pulled into the 0.6 branch 
> as an added feature.
> https://github.com/jimmypc92/qpid-proton/tree/AndroidProton
> Issues porting Proton-C to Android
> The first issue of getting Proton-C working on Android was the lack of 
> openssl and uuid support. I fixed this by using open source implementations I 
> found online. My openssl for Android implementation was acquired off an old 
> github repository 
> "https://github/eighthave/openssl-android.git;
> My uuid for Android implementation was acquired from AOSP
> "android/platform/external/e2fsprogs/./lib/uuid"
> Building the C libraries for Android
> I built these libraries using the ndk-build system that comes with the 
> Android ndk. My folder comes with a README that links to the Android ndk if 
> one does not already have it. The README folder also has step-by-step 
> instructions for someone to build the library their selves. As I said, this 
> involves calling ndk-build 3 times. The user will build the openssl, then the 
> uuid, then the Proton-C libraries. The user can create their own java 
> bindings for calling the c library from Android by building the desktop 
> Qpid-Proton-0.6 with java swig bindings. Or they can use the jars that come 
> with my folder.
> Changes
> Every occurrence of getprotobyname("tcp")->p_proto had to be replaced with 
> IPPROTO_TCP in the source file proton-c/src/posix/driver.c This fix checks if 
> the source is being compiled with the NDK compiler to ensure that it doesn't 
> break the desktop build. The pre-processor definition for Android is 
> #ifdef __ANDROID__
> functional bug fix
> The swig language binding jars produced with Qpid-Proton-0.6 build system 
> were causing a segfault whenever receiving a message that had the messageId 
> set to a generated uuid from the desktop Qpid-Proton-0.6 client. The error is 
> in JNIMessage.java in 
> qpid-proton-0.6/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/messsage/jni.
>  at the convert method whenever type is a uuid.
> The fix I used involved removing the use of pn_bytes_to_array in favor of 
> getting a pn_uuid_t from value (which is a pn_atom_t_u) and then getting the 
> byte array directly from the pn_uuid_t with the pn_uuid_t.getBytes() method 
> call.
> {code:title=JNIMessage.java|borderStyle=solid}
> else if(pn_type_t.PN_UUID.equals(type))
> {
>  pn_uuid_t uuidT = value.getAs_uuid();
>  byte[] uuidBytes = uuidT.getBytes();
>  -deleted- byte[] b = Proton.pn_bytes_to_array(value.getAs_bytes());
>  ByteBuffer buf = ByteBuffer.wrap(uuidBytes);
>  return new UUID(buf.getLong(), buf.getLong());
> }
> {code}
> Example Android project
> In the AndroidProtonBuild folder, a sample Android Proton project is included 
> that uses Proton-C. This project contains a file called UsingSwig.java which 
> exposes simple methods like send(). This sample project has a send and 
> receive button to check if the function is working with your target messaging 
> endpoint. The address to send and receive from must be specified in the 
> UsingSwig.java source file.
> tip for native development on android
> If you want to check for compilation by the NDK build system use
> #ifdef __ANDROID__
> If you want to use eclipse and print to LogCat from C code, include the 
> following lines at the top of the source file:
> #ifdef __ANDROID__
> #include 
> #define LOG_TAG   "my-log-tag"
> #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__)
> #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__)
> #endif
>  These lines allow you to call LOGD([stringToPrint]); Which basically serves 
> as a 

[jira] [Closed] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1

[Justin Ross (JIRA)]

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

Justin Ross closed PROTON-1073.
---
Resolution: Fixed

> Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
> ---
>
> Key: PROTON-1073
> URL: https://issues.apache.org/jira/browse/PROTON-1073
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.0
> Environment: MacOS X 10.11.1, XCode 7.1.1
> Compilation options:
> env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake 
> .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF 
> -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64
>Reporter: Ollivier Robert
>Assignee: Cliff Jansen
>  Labels: build-failure, osx
>
> Compiling 0.11 leads to build failure in the tests for the C++ bindings:
> [...]
> Linking CXX shared library libqpid-proton-cpp.dylib
> [ 66%] Built target qpid-proton-cpp
> Scanning dependencies of target conversion_test
> [ 66%] Building CXX object 
> proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p = s.ptr();
> ^   ~~~
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25:
>  note:
>   in instantiation of function template specialization
>   'test_owning   std::__1::default_delete >,
>   std::__1::unique_ptr std::__1::default_delete > >'
>   requested here
> failed += run_test(_owning<
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p2 = s.ptr();
> ^~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> 2 errors generated.
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o]
>  Error 1
> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error 
> 2
> make: *** [all] Error 2



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

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

[jira] [Reopened] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1

[Justin Ross (JIRA)]

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

Justin Ross reopened PROTON-1073:
-

> Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
> ---
>
> Key: PROTON-1073
> URL: https://issues.apache.org/jira/browse/PROTON-1073
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.0
> Environment: MacOS X 10.11.1, XCode 7.1.1
> Compilation options:
> env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake 
> .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF 
> -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64
>Reporter: Ollivier Robert
>Assignee: Cliff Jansen
>  Labels: build-failure, osx
> Fix For: 0.12.0
>
>
> Compiling 0.11 leads to build failure in the tests for the C++ bindings:
> [...]
> Linking CXX shared library libqpid-proton-cpp.dylib
> [ 66%] Built target qpid-proton-cpp
> Scanning dependencies of target conversion_test
> [ 66%] Building CXX object 
> proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p = s.ptr();
> ^   ~~~
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25:
>  note:
>   in instantiation of function template specialization
>   'test_owning   std::__1::default_delete >,
>   std::__1::unique_ptr std::__1::default_delete > >'
>   requested here
> failed += run_test(_owning<
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p2 = s.ptr();
> ^~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> 2 errors generated.
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o]
>  Error 1
> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error 
> 2
> make: *** [all] Error 2



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

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

[jira] [Updated] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1073:

Labels: build-failure osx  (was: build-failure)

> Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
> ---
>
> Key: PROTON-1073
> URL: https://issues.apache.org/jira/browse/PROTON-1073
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.11.0
> Environment: MacOS X 10.11.1, XCode 7.1.1
> Compilation options:
> env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake 
> .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF 
> -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64
>Reporter: Ollivier Robert
>Assignee: Cliff Jansen
>  Labels: build-failure, osx
>
> Compiling 0.11 leads to build failure in the tests for the C++ bindings:
> [...]
> Linking CXX shared library libqpid-proton-cpp.dylib
> [ 66%] Built target qpid-proton-cpp
> Scanning dependencies of target conversion_test
> [ 66%] Building CXX object 
> proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p = s.ptr();
> ^   ~~~
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25:
>  note:
>   in instantiation of function template specialization
>   'test_owning   std::__1::default_delete >,
>   std::__1::unique_ptr std::__1::default_delete > >'
>   requested here
> failed += run_test(_owning<
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17:
>  error:
>   no viable constructor copying variable of type 
> 'std::unique_ptr'
> session_ptr p2 = s.ptr();
> ^~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5:
>  note:
>   candidate constructor not viable: expects an l-value for 1st argument
> unique_ptr(unique_ptr&);
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9:
>  note:
>   candidate constructor [with _Up = proton::session, _Ep =
>   std::__1::default_delete] not viable: expects an 
> l-value for 1st
>   argument
> unique_ptr(unique_ptr<_Up, _Ep>&);
> ^
> 2 errors generated.
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o]
>  Error 1
> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error 
> 2
> make: *** [all] Error 2



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

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

[jira] [Updated] (PROTON-731) Installing language bindings provides no means to override the install path

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-731:
---
Fix Version/s: Future

> Installing language bindings provides no means to override the install path
> ---
>
> Key: PROTON-731
> URL: https://issues.apache.org/jira/browse/PROTON-731
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Darryl L. Pierce
>  Labels: patch
> Fix For: Future
>
> Attachments: 
> 0001-PROTON-731-Installing-Python-requires-Proton-be-inst.patch
>
>
> When performing an install, such as with Fedora or Ubuntu packaging, the 
> python installation bits use setuptools to build and install the bindings. 
> However, since the code isn't necessarily installed at that point the install 
> fails with:
> running sdist
> running check
> warning: sdist: manifest template 'MANIFEST.in' does not exist (using default 
> file list)
> warning: sdist: standard file not found: should have one of README, README.txt
> writing manifest file 'MANIFEST'
> creating python-qpid-proton-0.8-0
> making hard links in python-qpid-proton-0.8-0...
> hard linking cproton.py -> python-qpid-proton-0.8-0
> hard linking cprotonPYTHON_wrap.c -> python-qpid-proton-0.8-0
> hard linking proton.py -> python-qpid-proton-0.8-0
> hard linking setup.py -> python-qpid-proton-0.8-0
> creating dist
> Creating tar archive
> removing 'python-qpid-proton-0.8-0' (and everything under it)
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.7
> copying proton.py -> build/lib.linux-x86_64-2.7
> copying cproton.py -> build/lib.linux-x86_64-2.7
> running build_ext
> building '_cproton' extension
> creating build/temp.linux-x86_64-2.7
> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv 
> -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
> -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Itemp/usr/local/include 
> -I/usr/include/python2.7 -c cprotonPYTHON_wrap.c -o 
> build/temp.linux-x86_64-2.7/cprotonPYTHON_wrap.o
> cprotonPYTHON_wrap.c:3019:24: fatal error: proton/url.h: No such file or 
> directory
>  #include 
> ^
> compilation terminated.
> ERROR:root:setup failed!



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

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

[jira] [Updated] (PROTON-852) Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support getaddrinfo(),getprotobyname()

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-852:
---
Labels: close-pending patch  (was: patch)

> Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support 
> getaddrinfo(),getprotobyname() 
> -
>
> Key: PROTON-852
> URL: https://issues.apache.org/jira/browse/PROTON-852
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Affects Versions: 0.9, 0.9.1, 0.10
> Environment: uclinux m68k
>Reporter: Tomasz Nowicki
>Assignee: Andrew Stitcher
>  Labels: close-pending, patch
> Attachments: proton-c-GETADDRINFO.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> We are using proton-c on a small ebedded system based on uclinux/uclibc.c On 
> this platform several required functions ex getaddrinfo(), getprotobyname() 
> are not implemented.We added support for this type of platform by wraping 
> with pn_getaddrinfo,pn_getprotobyname.  Relevant pn_freeaddrinfo is also 
> introduced. If GETADDRINFO_NOT_IMPL flag is not present, native 
> implementation is called. Changes apply for posix versions that use old lib.c 
> Specifically in some embedded versions "get host" is not present(ip address 
> is used instead).



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

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

[jira] [Updated] (PROTON-692) Add php build on composer

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-692:
---
Labels: messenger  (was: php php-proton)

> Add php build on composer
> -
>
> Key: PROTON-692
> URL: https://issues.apache.org/jira/browse/PROTON-692
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: php-binding
>Reporter: Haag Olivier
>Priority: Minor
>  Labels: messenger
>
> Would it be possible to make the php build pullable from composer ?
> https://getcomposer.org/
> https://packagist.org/



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

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

[jira] [Updated] (PROTON-366) Add a protocol dump utility for java

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-366:
---
Labels: close-pending patch  (was: patch)

> Add a protocol dump utility for java
> 
>
> Key: PROTON-366
> URL: https://issues.apache.org/jira/browse/PROTON-366
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.4
>Reporter: Justin Ross
>Priority: Minor
>  Labels: close-pending, patch
> Attachments: QPID-4106.patch
>
>
> This bug was originally under the QPID jira instance.



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

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

[jira] [Updated] (PROTON-793) error LNK2019: unresolved external symbol _pn_selector_size referenced in function _pn_reactor_work

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-793:
---
Assignee: Chuck Rolke

> error LNK2019: unresolved external symbol _pn_selector_size referenced in 
> function _pn_reactor_work
> ---
>
> Key: PROTON-793
> URL: https://issues.apache.org/jira/browse/PROTON-793
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Windows, Visual Studio 8 2005
>Reporter: daniel
>Assignee: Chuck Rolke
>  Labels: build-failure, close-pending
>
> function pn_selector_sized is declared in selector.h, used in reactor.c
> Could not find its definition in any file. 
> I guess this is a wrapper around struct pn_selector_t.



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

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

[jira] [Updated] (PROTON-692) Add php build on composer

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-692:
---
Component/s: php-binding

> Add php build on composer
> -
>
> Key: PROTON-692
> URL: https://issues.apache.org/jira/browse/PROTON-692
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: php-binding
>Reporter: Haag Olivier
>Priority: Minor
>  Labels: php, php-proton
>
> Would it be possible to make the php build pullable from composer ?
> https://getcomposer.org/
> https://packagist.org/



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

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

[jira] [Updated] (PROTON-793) error LNK2019: unresolved external symbol _pn_selector_size referenced in function _pn_reactor_work

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-793:
---
Labels: build-failure close-pending  (was: build)

> error LNK2019: unresolved external symbol _pn_selector_size referenced in 
> function _pn_reactor_work
> ---
>
> Key: PROTON-793
> URL: https://issues.apache.org/jira/browse/PROTON-793
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Windows, Visual Studio 8 2005
>Reporter: daniel
>  Labels: build-failure, close-pending
>
> function pn_selector_sized is declared in selector.h, used in reactor.c
> Could not find its definition in any file. 
> I guess this is a wrapper around struct pn_selector_t.



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

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

[jira] [Updated] (PROTON-353) DecoderImpl returns private UnknownDescribedType instead of ...amqp.UnknownDescribedType

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-353:
---
Fix Version/s: 0.17.0

> DecoderImpl returns private UnknownDescribedType instead of 
> ...amqp.UnknownDescribedType
> 
>
> Key: PROTON-353
> URL: https://issues.apache.org/jira/browse/PROTON-353
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.4
> Environment: Windows / Eclipse Juno
>Reporter: Sean Gallagher
>Priority: Minor
>  Labels: api, codec
> Fix For: 0.17.0
>
>
> DecoderImpl.java creates and exposes to the application, instances of a 
> private class UnknownDescribedType. It should probably instantiate instances 
> of org.apache.qpid.proton.amqp.UnknownDescribedType.



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

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

[jira] [Updated] (PROTON-353) DecoderImpl returns private UnknownDescribedType instead of ...amqp.UnknownDescribedType

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-353:
---
Labels: api codec  (was: codec)

> DecoderImpl returns private UnknownDescribedType instead of 
> ...amqp.UnknownDescribedType
> 
>
> Key: PROTON-353
> URL: https://issues.apache.org/jira/browse/PROTON-353
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.4
> Environment: Windows / Eclipse Juno
>Reporter: Sean Gallagher
>Priority: Minor
>  Labels: api, codec
> Fix For: 0.17.0
>
>
> DecoderImpl.java creates and exposes to the application, instances of a 
> private class UnknownDescribedType. It should probably instantiate instances 
> of org.apache.qpid.proton.amqp.UnknownDescribedType.



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

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

[jira] [Updated] (PROTON-335) Need a means of specifying and reading link properties

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-335:
---
Labels: api close-pending  (was: api)

> Need a means of specifying and reading link properties
> --
>
> Key: PROTON-335
> URL: https://issues.apache.org/jira/browse/PROTON-335
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: Gordon Sim
>Priority: Minor
>  Labels: api, close-pending
>
> There are some cases where it may be beneficial to use link properties (since 
> link capabilities do not allow for key-value pairs, they can't easily convey 
> a desired configurable value and the properties on a terminus refer to the 
> dynamically created node not the link or the terminus itself).
> (I've set this to minor since major feels a little strong, but I do think its 
> important ultimately for the engine to expose all the extension points from 
> the protocol.)



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

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

[jira] [Updated] (PROTON-291) fix the SSL layer of the transport to only pop from the amqp layer when bytes are known to have actually been written to the socket

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-291:
---
Labels: close-pending ssl  (was: ssl)

> fix the SSL layer of the transport to only pop from the amqp layer when bytes 
> are known to have actually been written to the socket
> ---
>
> Key: PROTON-291
> URL: https://issues.apache.org/jira/browse/PROTON-291
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Rafael H. Schloming
>Assignee: Ken Giusti
>  Labels: close-pending, ssl
>




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

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

[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-287:
---
Fix Version/s: 0.17.0

> Fix Qpid Proton-C build with MinGW on Fedora
> 
>
> Key: PROTON-287
> URL: https://issues.apache.org/jira/browse/PROTON-287
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.4
> Environment: mingw32-gcc-4.7.2-7.fc18.x86_64
>Reporter: Robin Lee
>Assignee: Cliff Jansen
>  Labels: build, close-pending, patch
> Fix For: 0.17.0
>
>
> This is my first submit on ASF JIRA.
> Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided:
> Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff
> Description: %z format specifier is not provided by MSVCRT, use MinGW version 
> of *printf to get it. Otherwise build failed with: 
> "proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 
> 'z' in format [-Werror=format]"
> Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff
> Description: Libraries and header files should be written in small cases, 
> otherwise build failed in cross build environment of Unix-like platforms: 
> "proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file 
> or directory"
> Patch 3: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff
> Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, 
> since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build 
> failed with: "proton-c/src/windows/driver.c:785:11: error: comparison between 
> signed and unsigned integer expressions [-Werror=sign-compare]"
> Patch 4: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff
> Description: Commented unimplemented functions. Otherwise build failed with 
> "proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 
> 'static' but never defined [-Werror=unused-function]"
> Patch 5: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff
> Description:
> 1. ID is not used, build failed with "../wincompat/internal/getopt.c:43:20: 
> error: 'ID' defined but not used [-Werror=unused-variable]"
> 2. Corrected getopt signiture, otherwise build failed with 
> "proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' 
> but argument is of type 'const char *'"
> 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so 
> #include wincompat/getopt.h in .c files instead of .h, otherwise build failed 
> with multiple definitions.
> Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff
> Description: WIN32 macro is not defined with -std=c99 but defined with 
> -std=gnu99. Use _WIN32 macro in all places.
> Built on Fedora and examples of recv and send are tested on Windows 7.



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

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

[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-287:
---
Labels: build close-pending patch  (was: build patch)

> Fix Qpid Proton-C build with MinGW on Fedora
> 
>
> Key: PROTON-287
> URL: https://issues.apache.org/jira/browse/PROTON-287
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.4
> Environment: mingw32-gcc-4.7.2-7.fc18.x86_64
>Reporter: Robin Lee
>Assignee: Cliff Jansen
>  Labels: build, close-pending, patch
>
> This is my first submit on ASF JIRA.
> Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided:
> Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff
> Description: %z format specifier is not provided by MSVCRT, use MinGW version 
> of *printf to get it. Otherwise build failed with: 
> "proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 
> 'z' in format [-Werror=format]"
> Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff
> Description: Libraries and header files should be written in small cases, 
> otherwise build failed in cross build environment of Unix-like platforms: 
> "proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file 
> or directory"
> Patch 3: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff
> Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, 
> since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build 
> failed with: "proton-c/src/windows/driver.c:785:11: error: comparison between 
> signed and unsigned integer expressions [-Werror=sign-compare]"
> Patch 4: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff
> Description: Commented unimplemented functions. Otherwise build failed with 
> "proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 
> 'static' but never defined [-Werror=unused-function]"
> Patch 5: 
> http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff
> Description:
> 1. ID is not used, build failed with "../wincompat/internal/getopt.c:43:20: 
> error: 'ID' defined but not used [-Werror=unused-variable]"
> 2. Corrected getopt signiture, otherwise build failed with 
> "proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' 
> but argument is of type 'const char *'"
> 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so 
> #include wincompat/getopt.h in .c files instead of .h, otherwise build failed 
> with multiple definitions.
> Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff
> Description: WIN32 macro is not defined with -std=c99 but defined with 
> -std=gnu99. Use _WIN32 macro in all places.
> Built on Fedora and examples of recv and send are tested on Windows 7.



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

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

[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-252:
---
Labels: api close-pending  (was: visibility)

> Reduce visibiliy of constructors for classes that should be created by 
> factories eg MessageImpl
> ---
>
> Key: PROTON-252
> URL: https://issues.apache.org/jira/browse/PROTON-252
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.4
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>Priority: Minor
>  Labels: api, close-pending
> Fix For: 0.17.0
>
>
> These constructors are currently public but deprecated, and should be made 
> package-private where possible to enforce the use of the factories instead.



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

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

[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-252:
---
Fix Version/s: 0.17.0

> Reduce visibiliy of constructors for classes that should be created by 
> factories eg MessageImpl
> ---
>
> Key: PROTON-252
> URL: https://issues.apache.org/jira/browse/PROTON-252
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.4
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>Priority: Minor
>  Labels: visibility
> Fix For: 0.17.0
>
>
> These constructors are currently public but deprecated, and should be made 
> package-private where possible to enforce the use of the factories instead.



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

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

[jira] [Updated] (PROTON-241) proton-c: mark old transport interfaces 'deprecated'

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-241:
---
Fix Version/s: 0.16.0

> proton-c: mark old transport interfaces 'deprecated'
> 
>
> Key: PROTON-241
> URL: https://issues.apache.org/jira/browse/PROTON-241
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ken Giusti
>Priority: Trivial
>  Labels: api
> Fix For: 0.16.0
>
>
> Once PROTON-225 is implemented, we should eventually remove the old 
> interfaces after marking them deprecated.
> Example:
> #ifdef __GNUC__
> #define DEPRECATED(func) func __attribute__ ((deprecated))
> #elif defined(_MSC_VER)
> #define DEPRECATED(func) __declspec(deprecated) func
> #else
> #pragma message("WARNING: You need to implement DEPRECATED for this compiler")
> #define DEPRECATED(func) func
> #endif



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

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

[jira] [Updated] (PROTON-220) Create a set of "glass box" tests to quantify the performance of the proton codebase.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-220:
---
Fix Version/s: 0.17.0

> Create a set of "glass box" tests to quantify the performance of the proton 
> codebase.
> -
>
> Key: PROTON-220
> URL: https://issues.apache.org/jira/browse/PROTON-220
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c, proton-j
>Reporter: Ken Giusti
>Assignee: michael goulish
>  Labels: perfomance, test
> Fix For: 0.17.0
>
>
> The goal of these tests would be to detect any performance degradation 
> inadvertently introduced during development.   These tests would not be 
> intended to provide any metrics regarding the "real world" behavior of 
> proton-based applications.  Rather, these tests are targeted for use by the 
> proton developers to help gauge the effect their code changes may have on 
> performance.
> These tests should require no special configuration or setup in order to run. 
>  It should be easy to run these test as part of the development process.  The 
> intent would be to have developer run the tests prior to making any code 
> changes, and record the metrics for comparison against the results obtained 
> after making changes to the code base.
> As described by Rafi:
> "I think it would be good to include some performance metrics that isolate
> the various components of proton. For example having a metric that simply
> repeatedly encodes/decodes a message would be quite useful in isolating the
> message implementation. Setting up two engines in memory and using them to
> blast zero sized messages back and forth as fast as possible would tell us
> how much protocol overhead the engine is adding. Using the codec directly
> to encode/decode data would also be a useful measure. Each of these would
> probably want to have multiple profiles, different message content,
> different acknowledgement/flow control patterns, and different kinds of
> data.
> I think breaking out the different dimensions of the implementation as
> above would provide a very useful tool to run before/after any performance
> sensitive changes to detect and isolate regressions, or to test potential
> improvements."



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

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

[jira] [Updated] (PROTON-162) SSL implementation does not support certification revocation

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-162:
---
Fix Version/s: Future

> SSL implementation does not support certification revocation
> 
>
> Key: PROTON-162
> URL: https://issues.apache.org/jira/browse/PROTON-162
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.3
>Reporter: Ken Giusti
>  Labels: security, ssl
> Fix For: Future
>
>
> OpenSSL supports a means for configuring lists of revoked certificates.   The 
> SSL layer used by proton-c does not provide a means to configure this.



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

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

[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-161:
---
Labels: close-pending security  (was: security)

> SSL impl does not allow verification of the peer's identity
> ---
>
> Key: PROTON-161
> URL: https://issues.apache.org/jira/browse/PROTON-161
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.3
>Reporter: Ken Giusti
>Priority: Minor
>  Labels: close-pending, security
>
> The current SSL implementation validates the peer's certificate, and will not 
> permit the connection to come up if the certificate is invalid.
> However - it does not provide a way to check if the peer's identity as 
> provided in the certificate is the expected identity (eg, the same hostname 
> used to set up the TCP connection).  While a certificate may be valid (that 
> is, signed by a CA trusted by the client), it may not belong to the intended 
> destination.
> RFC2818 explains how this should be done - see section 3.1 Server Identity. 



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

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

[jira] [Updated] (PROTON-73) Server should force renegotiate when client authentication setting is changed on an active connection.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-73:
--
Fix Version/s: Future

> Server should force renegotiate when client authentication setting is changed 
> on an active connection.
> --
>
> Key: PROTON-73
> URL: https://issues.apache.org/jira/browse/PROTON-73
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: security, ssl
> Fix For: Future
>
>
> If the server application changes the peer authentication setting from 
> 'anonymous' to 'verify-peer' while an SSL session is active, then the server 
> should force the client to re-negotiate (SSL handshake) to verify the 
> remote's identity.



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

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

[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-158:
---
Labels: close-pending crash  (was: crash)

> detach with invalid handle causes segfault
> --
>
> Key: PROTON-158
> URL: https://issues.apache.org/jira/browse/PROTON-158
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.2
>Reporter: Gordon Sim
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: close-pending, crash
> Fix For: 0.17.0
>
>
> I.e. a detach where the handle was not previously used in an attach



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

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

[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-158:
---
Fix Version/s: 0.17.0

> detach with invalid handle causes segfault
> --
>
> Key: PROTON-158
> URL: https://issues.apache.org/jira/browse/PROTON-158
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.2
>Reporter: Gordon Sim
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: close-pending, crash
> Fix For: 0.17.0
>
>
> I.e. a detach where the handle was not previously used in an attach



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

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

[jira] [Updated] (PROTON-357) Add PHP PECL package

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-357:
---
Labels: messenger packaging  (was: packaging)

> Add PHP PECL package
> 
>
> Key: PROTON-357
> URL: https://issues.apache.org/jira/browse/PROTON-357
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Affects Versions: 0.4
> Environment: Linux, Macos X
>Reporter: Serge Smertin
>  Labels: messenger, packaging
>
> In order to get Proton adoption in PHP ecosystem and not to build library 
> from sources, PECL package should be introduced. Probably with Packagist as 
> well.



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

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