[jira] [Closed] (PROTON-909) Tests for new SASL features and mechanisms
[ https://issues.apache.org/jira/browse/PROTON-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher closed PROTON-909. -- Resolution: Fixed > Tests for new SASL features and mechanisms > -- > > Key: PROTON-909 > URL: https://issues.apache.org/jira/browse/PROTON-909 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1095) Error handling
Andrew Stitcher created PROTON-1095: --- Summary: Error handling Key: PROTON-1095 URL: https://issues.apache.org/jira/browse/PROTON-1095 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher The C++ binding needs a disciplined and effective way to handle protocol (and transport) errors. Currently the API has some error events, however if they are not handled the program will just hang - it would be better in this case to throw an exception so that the program doesn't just hang. Another issue is creating error states (attaching a condition) when closing a connection/session/link - there should be some straightforward way to indicate the error to your peer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-626) Add CMake build output files to gitignore
[
https://issues.apache.org/jira/browse/PROTON-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-626.
Resolution: Won't Fix
Building using CMake is not intended to be done in the source directory.
Please create a new directory for the build and run cmake there.
> Add CMake build output files to gitignore
> -
>
> Key: PROTON-626
> URL: https://issues.apache.org/jira/browse/PROTON-626
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Affects Versions: 0.7
> Environment: CentOS 6.5
>Reporter: Teerapap Changwichukarn
>Priority: Minor
> Attachments: 0001-qpid-proton-Ignore-CMake-output-files.patch
>
>
> I run these commands below.
> {{cmake . -DCMAKE_INSTALL_PREFIX=build -DNOBUILD_JAVA=ON
> -DSYSINSTALL_BINDINGS=OFF}}
> {{make all}}
> There are some build output files from this command. I think they should be
> in gitignore.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-635. Resolution: Fixed Fix Version/s: 0.9 I think the problems that are mentioned in this bug have now been fixed. If not we can reopen this bug. [Or create a linked bug if an new issue is related] > PN_TRANSPORT events not generated in enough places > -- > > Key: PROTON-635 > URL: https://issues.apache.org/jira/browse/PROTON-635 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.9 > > > In writing a custom driver for Proton I noticed thatthe new events code does > not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol > header. > So a purely event driven driver is not going to send the outgoing protocol > header immediately, but is going to wait until it replies to the next frame > (open). > Also in error scenarios no PN_TRANSPORT is generated after the open/close > frames are generated. > This is going to end badly if the peer is waiting for the protocol header > before sending the open. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-594) In tree builds with cmake causes issues when running python based tests
[ https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-594. Resolution: Won't Fix In tree builds are not supported. CMake will do in tree builds, but they are strongly discouraged. > In tree builds with cmake causes issues when running python based tests > --- > > Key: PROTON-594 > URL: https://issues.apache.org/jira/browse/PROTON-594 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Rajith Attapattu >Assignee: Rafael H. Schloming > > If we do an in-tree build it causes path issues when trying to run the python > based tests against the java code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[
https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089812#comment-15089812
]
Andrew Stitcher commented on PROTON-411:
I think this assertion is incorrect: The pkg-config stuff is only used (and
useful) for gcc (or similar compilers) not visual studio. Therefore the command
liine options should be for gcc etc. and deosn't need changing.
To amplify:
The only sensible way to use pkg-config on Windows is under cygwin (or maybe
mingw) and for that these file contents would be okay.
[Or did I miss something?]
> [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
> -
>
> Key: PROTON-411
> URL: https://issues.apache.org/jira/browse/PROTON-411
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.4
> Environment: Windows
>Reporter: Chuck Rolke
> Labels: windows
>
> Windows needs something other than hard coded
> Libs: -L${libdir -lqpid-proton
> Cflags: -I${includedir}}
> All the other computed values configured into this file are correct: PREFIX,
> EXEC_PREFIX, LIBDIR, INCLUDEDIR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
[
https://issues.apache.org/jira/browse/PROTON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-411.
Resolution: Won't Fix
> [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
> -
>
> Key: PROTON-411
> URL: https://issues.apache.org/jira/browse/PROTON-411
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.4
> Environment: Windows
>Reporter: Chuck Rolke
> Labels: windows
>
> Windows needs something other than hard coded
> Libs: -L${libdir -lqpid-proton
> Cflags: -I${includedir}}
> All the other computed values configured into this file are correct: PREFIX,
> EXEC_PREFIX, LIBDIR, INCLUDEDIR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-332) SASL module needs access to the SSL module
[ https://issues.apache.org/jira/browse/PROTON-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-332. Resolution: Fixed This has been rendered entirely moot by the SASL work on PROTON-334, which implement SASL EXTERNAL. > SASL module needs access to the SSL module > -- > > Key: PROTON-332 > URL: https://issues.apache.org/jira/browse/PROTON-332 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: security > > The SASL interface needs to be extended with a function that provides a > pointer to an SSL session. This is needed because the EXTERNAL mechanism > handshake requires access to the authentication ID from the external (ssl) > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-206) Use const char* variables for string literals
[ https://issues.apache.org/jira/browse/PROTON-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-206. Resolution: Fixed Closing old bug: I think this has been fixed., but in any case these uses would cause a type mismatch when compiling in C++. > Use const char* variables for string literals > - > > Key: PROTON-206 > URL: https://issues.apache.org/jira/browse/PROTON-206 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: all >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > > proton sometimes uses declarations of the form > char *host = "0.0.0.0"; > These should be hunted down and replaced with a const declaration. Where > these variables are passed as arguments to other functions, those should be > additionally changed to const where appropriate. This occurs in > examples/messenger/c/send.c > examples/messenger/c/recv.c > src/messenger.c > src/util.c > src/proton.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-248) Subordinate CMakeLists.txt files should not build on their own
[ https://issues.apache.org/jira/browse/PROTON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-248. Resolution: Won't Fix > Subordinate CMakeLists.txt files should not build on their own > -- > > Key: PROTON-248 > URL: https://issues.apache.org/jira/browse/PROTON-248 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Affects Versions: 0.4 > Environment: Windows, perhaps all. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > If CMake is pointed to the wrong (subordinate, instead of top level) > directory, the CMakeLists.txt file should detect the problem and exit with a > clear error message instead of generating a bogus build accompanied by a > vague warning. > To reproduce: > cd trunk\proton-c > mkdir build > cd build > cmake [args] .. > [build away] > In which case cmake uses trunk/proton-c/CMakeLists.txt as the top level > instead of trunk/CMakeLists.txt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-152) SASL architecture does not support security layers
[ https://issues.apache.org/jira/browse/PROTON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-152. Resolution: Fixed This is now implemented. > SASL architecture does not support security layers > -- > > Key: PROTON-152 > URL: https://issues.apache.org/jira/browse/PROTON-152 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross > Labels: security > > SASL can optionally insert a security layer in the data stream for a > connection. The security layer encrypts/signs/decrypts the data stream. In > this way it is architecturally similar to SSL: It performs a handshake > in-the-clear and then inserts itself into the stream to provide link security. > Without this support, mechanisms like GSSAPI (Kerberos5) cannot be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-248) Subordinate CMakeLists.txt files should not build on their own
[ https://issues.apache.org/jira/browse/PROTON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089866#comment-15089866 ] Andrew Stitcher commented on PROTON-248: I think this is intentional behaviour on the part of cmake - it is not unusual to have sub directories that have cmake build systems that are self contained and could work on their own. > Subordinate CMakeLists.txt files should not build on their own > -- > > Key: PROTON-248 > URL: https://issues.apache.org/jira/browse/PROTON-248 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Affects Versions: 0.4 > Environment: Windows, perhaps all. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > If CMake is pointed to the wrong (subordinate, instead of top level) > directory, the CMakeLists.txt file should detect the problem and exit with a > clear error message instead of generating a bogus build accompanied by a > vague warning. > To reproduce: > cd trunk\proton-c > mkdir build > cd build > cmake [args] .. > [build away] > In which case cmake uses trunk/proton-c/CMakeLists.txt as the top level > instead of trunk/CMakeLists.txt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-272) Run tests on an installed system.
[ https://issues.apache.org/jira/browse/PROTON-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-272: --- Priority: Minor (was: Major) > Run tests on an installed system. > - > > Key: PROTON-272 > URL: https://issues.apache.org/jira/browse/PROTON-272 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > Reduce duplication of paths etc. between config.sh and CMakeList.txt. Provide > a way to run the tests on an installed system. > The config.sh in the proton root directory does all the environmental > configuration necessary for each of the bindings to find appropriate modules, > etc. It's really handy for when you want to run code/examples on the command > line out of a source tree build rather than having to install everything. I > believe much of that logic is duplicated here. I know the config.sh isn't > exactly cross-platform, but is there a way to eliminate or reduce some of the > duplication? > A related question is how to run these tests off of an installed system. > Right now the tests appear to pass, however if you actually try and install > the ruby binding and run anything you can't even import the module because > the install is messed up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-215) Add tests to verify AMQP 1.0 type support for all language bindings
[ https://issues.apache.org/jira/browse/PROTON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-215: --- Assignee: (was: Alan Conway) > Add tests to verify AMQP 1.0 type support for all language bindings > --- > > Key: PROTON-215 > URL: https://issues.apache.org/jira/browse/PROTON-215 > Project: Qpid Proton > Issue Type: Test > Components: proton-c >Affects Versions: 0.3 >Reporter: Ken Giusti > Labels: test > > For each language binding, we need to verify that the language can encode to > and decode from the AMQP 1.0 types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-272) Run tests on an installed system.
[ https://issues.apache.org/jira/browse/PROTON-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-272: --- Assignee: (was: Alan Conway) > Run tests on an installed system. > - > > Key: PROTON-272 > URL: https://issues.apache.org/jira/browse/PROTON-272 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Alan Conway >Priority: Minor > > Reduce duplication of paths etc. between config.sh and CMakeList.txt. Provide > a way to run the tests on an installed system. > The config.sh in the proton root directory does all the environmental > configuration necessary for each of the bindings to find appropriate modules, > etc. It's really handy for when you want to run code/examples on the command > line out of a source tree build rather than having to install everything. I > believe much of that logic is duplicated here. I know the config.sh isn't > exactly cross-platform, but is there a way to eliminate or reduce some of the > duplication? > A related question is how to run these tests off of an installed system. > Right now the tests appear to pass, however if you actually try and install > the ruby binding and run anything you can't even import the module because > the install is messed up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-829) Possible reference counting bug in pn_clear_tpwork
[
https://issues.apache.org/jira/browse/PROTON-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-829.
Resolution: Fixed
Fix Version/s: 0.12.0
Verified fixed on current master, transport/connection can be freed in any
order. Don't know what commits fixed it.
> Possible reference counting bug in pn_clear_tpwork
> --
>
> Key: PROTON-829
> URL: https://issues.apache.org/jira/browse/PROTON-829
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> See QPID-6415 which describes a core dump in the qpid tests that appears when
> using the current 0.9 proton master. The qpid tests pass OK with proton 0.8.
> The valgrind output in QPID-6415 shows that a connection is deleted while it
> is being finalized by a call from pn_connection_unbound to pn_clear_tpwork.
> I do not yet understand the details, but removing the following strange code
> fixes the problem and passes the proton test suite without valgrind errors:
> {noformat}
> --- a/proton-c/src/engine/engine.c
> +++ b/proton-c/src/engine/engine.c
> @@ -690,10 +690,10 @@ void pn_clear_tpwork(pn_delivery_t *delivery)
>{
> LL_REMOVE(connection, tpwork, delivery);
> delivery->tpwork = false;
> -if (pn_refcount(delivery) > 0) {
> - pn_incref(delivery);
> - pn_decref(delivery);
> -}
>}
> }
> {noformat}
> The code is strange because
> a) you should never examine a refcount except for debugging purposes
> b) under normal refcounting semantics incref+decref is a no-op.
> Is removing this code OK?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-802:
--
Fix Version/s: 0.9
> Unicode strings passed in through python binding cause exceptions
> -
>
> Key: PROTON-802
> URL: https://issues.apache.org/jira/browse/PROTON-802
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
> Environment: Ubuntu 14.04.1 64-bit
>Reporter: Ken Leidal
>Assignee: Rafael H. Schloming
>Priority: Minor
> Labels: encoding, string
> Fix For: 0.9
>
>
> The following traceback was thrown when passing in a python unicode string
> for a host name. Ensuring the string is a python binary string (UTF-8) is a
> work around.
> {code:title=Traceback|borderStyle=solid}
> Traceback (most recent call last):
> File "./arc", line 246, in
> curses.wrapper(main)
> File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
> return func(stdscr, *args, **kwds)
> File "./arc", line 244, in main
> drv.run()
> File "/home/kkleidal/datawire/server/common.py", line 270, in run
> self.process_events()
> File "/home/kkleidal/datawire/server/common.py", line 315, in process_events
> ev.dispatch(h)
> File "/usr/lib/python2.7/dist-packages/proton/__init__.py", line 3365, in
> dispatch
> return dispatch(handler, self.type.method, self)
> File "/usr/lib/python2.7/dist-packages/proton/__init__.py", line 3311, in
> dispatch
> return m(*args)
> File "/home/kkleidal/datawire/server/common.py", line 723, in
> on_link_remote_close
> self.connect(network)
> File "/home/kkleidal/datawire/server/common.py", line 709, in connect
> self.conn.hostname = network.host
> File "/usr/lib/python2.7/dist-packages/proton/wrapper.py", line 54, in
> __setattr__
> object.__setattr__(self, name, value)
> File "/usr/lib/python2.7/dist-packages/proton/__init__.py", line 2319, in
> _set_hostname
> return pn_connection_set_hostname(self._impl, name)
> TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
> const *'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-577) CollectorImpl creates a lot of unnecessary garbage
[ https://issues.apache.org/jira/browse/PROTON-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-577. - > CollectorImpl creates a lot of unnecessary garbage > -- > > Key: PROTON-577 > URL: https://issues.apache.org/jira/browse/PROTON-577 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-493) channel max is not exposed
[ https://issues.apache.org/jira/browse/PROTON-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-493. - > channel max is not exposed > -- > > Key: PROTON-493 > URL: https://issues.apache.org/jira/browse/PROTON-493 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-493) channel max is not exposed
[ https://issues.apache.org/jira/browse/PROTON-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-493: -- Fix Version/s: 0.7 > channel max is not exposed > -- > > Key: PROTON-493 > URL: https://issues.apache.org/jira/browse/PROTON-493 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-665) SASL Servers need to be able to optionally handle clients that don't use SASL
[ https://issues.apache.org/jira/browse/PROTON-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-665. - Resolution: Fixed > SASL Servers need to be able to optionally handle clients that don't use SASL > - > > Key: PROTON-665 > URL: https://issues.apache.org/jira/browse/PROTON-665 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Rafael H. Schloming > Fix For: 0.10 > > > A proton-based server that uses SASL for authentication needs to be able to > optionally accept connections from clients that do not use SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-339) [Proton-J] Implement Data interface in pure Java
[ https://issues.apache.org/jira/browse/PROTON-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-339. --- Resolution: Fixed > [Proton-J] Implement Data interface in pure Java > - > > Key: PROTON-339 > URL: https://issues.apache.org/jira/browse/PROTON-339 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-951) Make install fails when building Proton-C with python 3.4
[
https://issues.apache.org/jira/browse/PROTON-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-951:
--
Fix Version/s: 0.10
Adding fix version.
> Make install fails when building Proton-C with python 3.4
> -
>
> Key: PROTON-951
> URL: https://issues.apache.org/jira/browse/PROTON-951
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: 0.10
>Reporter: Andrew Stitcher
>Assignee: Ken Giusti
> Fix For: 0.10
>
> Attachments: py34fail
>
>
> When building proton-C using a python 3.4 virtualenv make install fails:
> {noformat}
> $ source ~/LocalPython/Python3/bin/activate
> $ cmake -DCMAKE_INSTALL_PREFIX=$PWD/install ../src
> $ cmake --build . --target install
> {noformat}
> {noformat}
> ...
> CMake Error at proton-c/bindings/python/cmake_install.cmake:106 (file):
> file INSTALL cannot find
> "/home/andrew/Work/proton/bld-python3/proton-c/bindings/python/cproton.pyc".
> Call Stack (most recent call first):
> proton-c/bindings/cmake_install.cmake:37 (include)
> proton-c/cmake_install.cmake:139 (include)
> cmake_install.cmake:50 (include)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-928) Cancellable tasks
[ https://issues.apache.org/jira/browse/PROTON-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-928: -- Fix Version/s: 0.10 Adding fix version. > Cancellable tasks > - > > Key: PROTON-928 > URL: https://issues.apache.org/jira/browse/PROTON-928 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j, python-binding >Reporter: Bozo Dragojevic >Assignee: Bozo Dragojevic > Fix For: 0.10 > > > Allow scheduled tasks to be cancelled. > A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-262) Fully implement (error) condtion API in Proton-J
[ https://issues.apache.org/jira/browse/PROTON-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-262. --- Resolution: Fixed Resolving, changes were made in https://svn.apache.org/r1452846 > Fully implement (error) condtion API in Proton-J > > > Key: PROTON-262 > URL: https://issues.apache.org/jira/browse/PROTON-262 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-339) [Proton-J] Implement Data interface in pure Java
[ https://issues.apache.org/jira/browse/PROTON-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-339: -- Fix Version/s: 0.5 > [Proton-J] Implement Data interface in pure Java > - > > Key: PROTON-339 > URL: https://issues.apache.org/jira/browse/PROTON-339 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-262) Fully implement (error) condtion API in Proton-J
[ https://issues.apache.org/jira/browse/PROTON-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-262: -- Fix Version/s: 0.5 > Fully implement (error) condtion API in Proton-J > > > Key: PROTON-262 > URL: https://issues.apache.org/jira/browse/PROTON-262 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-696) The header file usage needs some improvement
[ https://issues.apache.org/jira/browse/PROTON-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-696. - Resolution: Fixed Fix Version/s: 0.9 Closing out old issue. > The header file usage needs some improvement > > > Key: PROTON-696 > URL: https://issues.apache.org/jira/browse/PROTON-696 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.9 > > > There are a number of small header file problems with proton. > * Some header files include too many other header files and so export too > many symbols - this is especially problematic if they use platform header > files. > * Conversely some header files are not self contained and do not define all > the symbols they use (by using the correct include files themselves) > * There are symbols exported in the installed header files which are internal > only symbols -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-918) Jython interop tests failing since e38957ae5115
[ https://issues.apache.org/jira/browse/PROTON-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-918. - Resolution: Done Closing old issue, tests were updated via the original jira such that they didnt fail, and a further JIRA is in place for making similar changes to proton-j. > Jython interop tests failing since e38957ae5115 > --- > > Key: PROTON-918 > URL: https://issues.apache.org/jira/browse/PROTON-918 > Project: Qpid Proton > Issue Type: Bug >Reporter: Andrew Stitcher >Assignee: michael goulish > > The change added tests that check for channel_max limit. > It seems this was implemented for Proton-C but not for Proton-J. > *It should be the rule to run the Proton-J tests and ensure they succeed > before making changes* -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-335) Need a means of specifying and reading link properties
[ https://issues.apache.org/jira/browse/PROTON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-335: -- Component/s: (was: proton-j) > 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 > > 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)
[jira] [Updated] (PROTON-1060) [Python Binding] API call types for some message properties do not match AMQP specification
[
https://issues.apache.org/jira/browse/PROTON-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1060:
---
Fix Version/s: 0.12.0
Adding fix version
> [Python Binding] API call types for some message properties do not match AMQP
> specification
> ---
>
> Key: PROTON-1060
> URL: https://issues.apache.org/jira/browse/PROTON-1060
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: 0.12.0
>
>
> Several of the Python binding API calls for message properties do not use the
> correct types. To align them properly with the AMQP 1.0 spec, the following
> APIs need changing:
> *Subject*
> The spec for this is: {{}}
> {{_get_subject()}} should return a unicode string, not a regular string;
> {{_set_subject()}} should accept a unicode string, not a regular string.
> *Content Type*
> The spec for this is: {{}}
> {{_get_content_type()}} should return a symbol, not a regular string;
> {{_set_content_type()}} should accept a symbol, not a regular string.
> *Content Encoding*
> The spec for this is: {{}}
> {{_get_content_encoding()}} should return a symbol, not a regular string;
> {{_set_content_encoding()}} should accept a symbol, not a regular string.
> *Group Id*
> The spec for this is: {{}}
> {{_get_group_id()}} should return a unicode string, not a regular string;
> {{_set_group_id()}} should accept a unicode string, not a regular string.
> *Reply-To Group Id*
> The spec for this is {{}}
> {{_get_reply_to_group_id()}} should return a unicode string, not a regular
> string;
> {{_set_reply_to_group_id()}} should accept a unicode string, not a regular
> string.
> The unicode string pattern is already established for other message property
> API calls such as {{_get/_set_address()}} and {{_get/_set_reply_to()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1084) [cpp binding] Add message annotation support
[ https://issues.apache.org/jira/browse/PROTON-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1084: --- Fix Version/s: 0.12.0 > [cpp binding] Add message annotation support > > > Key: PROTON-1084 > URL: https://issues.apache.org/jira/browse/PROTON-1084 > Project: Qpid Proton > Issue Type: Task > Components: cpp-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.12.0 > > > The current cpp binding does not expose message annotations. Add this support > so that c++ clients can access this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-951) Make install fails when building Proton-C with python 3.4
[
https://issues.apache.org/jira/browse/PROTON-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-951.
-
> Make install fails when building Proton-C with python 3.4
> -
>
> Key: PROTON-951
> URL: https://issues.apache.org/jira/browse/PROTON-951
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: 0.10
>Reporter: Andrew Stitcher
>Assignee: Ken Giusti
> Fix For: 0.10
>
> Attachments: py34fail
>
>
> When building proton-C using a python 3.4 virtualenv make install fails:
> {noformat}
> $ source ~/LocalPython/Python3/bin/activate
> $ cmake -DCMAKE_INSTALL_PREFIX=$PWD/install ../src
> $ cmake --build . --target install
> {noformat}
> {noformat}
> ...
> CMake Error at proton-c/bindings/python/cmake_install.cmake:106 (file):
> file INSTALL cannot find
> "/home/andrew/Work/proton/bld-python3/proton-c/bindings/python/cproton.pyc".
> Call Stack (most recent call first):
> proton-c/bindings/cmake_install.cmake:37 (include)
> proton-c/cmake_install.cmake:139 (include)
> cmake_install.cmake:50 (include)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-870. - Assignee: Andrew Stitcher > none_sasl.c should use pn_strdup > > > Key: PROTON-870 > URL: https://issues.apache.org/jira/browse/PROTON-870 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Dan Cristoloveanu >Assignee: Andrew Stitcher >Priority: Trivial > Fix For: 0.10 > > Original Estimate: 2h > Remaining Estimate: 2h > > none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does > not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-870: -- Fix Version/s: 0.10 > none_sasl.c should use pn_strdup > > > Key: PROTON-870 > URL: https://issues.apache.org/jira/browse/PROTON-870 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Dan Cristoloveanu >Priority: Trivial > Fix For: 0.10 > > Original Estimate: 2h > Remaining Estimate: 2h > > none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does > not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1090. Resolution: Fixed Assignee: Gordon Sim Validated Gordon's change - fix submitted. > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-510) hostname field in the Open command is not set
[ https://issues.apache.org/jira/browse/PROTON-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-510. - Resolution: Fixed This is working properly as of 0.11. I assume it was fixed much earlier but I haven't determined which release it was fixed in. > hostname field in the Open command is not set > - > > Key: PROTON-510 > URL: https://issues.apache.org/jira/browse/PROTON-510 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Ted Ross > > If an address of the form "amqp://dns.domain.com/path" is used in > Proton/Messenger, when the connection is opened, the hostname field in the > Open should contain "dns.domain.com". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089308#comment-15089308 ] ASF subversion and git services commented on PROTON-1090: - Commit 25d39a8e9cbf4846f23e4e58175d902924ec1a30 in qpid-proton's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=25d39a8 ] PROTON-1090: fix reactor timer pipe cleanup to prevent 100% cpu spin > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-542) Message.properties should default to an empty dictionary
[ https://issues.apache.org/jira/browse/PROTON-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-542. -- Resolution: Won't Fix > Message.properties should default to an empty dictionary > > > Key: PROTON-542 > URL: https://issues.apache.org/jira/browse/PROTON-542 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.7 >Reporter: Justin Ross > > Message.properties should default to an empty dictionary, not null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
