[jira] [Updated] (PROTON-1411) [C, Test] No self tests run when Swig is absent; report 100% pass

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1411:

Fix Version/s: proton-c-0.19.0

> [C, Test] No self tests run when Swig is absent; report 100% pass
> -
>
> Key: PROTON-1411
> URL: https://issues.apache.org/jira/browse/PROTON-1411
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
> Environment: Fedora 25, GCC 6.3.1, Python 2.7.13, master branch at 
> commit d5c01.
>Reporter: Chuck Rolke
>Assignee: Justin Ross
>  Labels: testing
> Fix For: proton-c-0.19.0
>
>
> If Swig is absent then the C self tests run in one or two seconds and report 
> 100% pass. Under the covers very few tests do any testing.
> {noformat}
> /home/chug/git/qpid-proton/build> ctest -VV
> ...
> 100% tests passed, 0 tests failed out of 18
> Total Test time (real) =   1.60 sec
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1411) [C, Test] No self tests run when Swig is absent; report 100% pass

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1411:

Labels: testing  (was: )

> [C, Test] No self tests run when Swig is absent; report 100% pass
> -
>
> Key: PROTON-1411
> URL: https://issues.apache.org/jira/browse/PROTON-1411
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
> Environment: Fedora 25, GCC 6.3.1, Python 2.7.13, master branch at 
> commit d5c01.
>Reporter: Chuck Rolke
>Assignee: Justin Ross
>  Labels: testing
> Fix For: proton-c-0.19.0
>
>
> If Swig is absent then the C self tests run in one or two seconds and report 
> 100% pass. Under the covers very few tests do any testing.
> {noformat}
> /home/chug/git/qpid-proton/build> ctest -VV
> ...
> 100% tests passed, 0 tests failed out of 18
> Total Test time (real) =   1.60 sec
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1414) heap-buffer-overflow in pni_decoder_decode_value when invoking pn_message_decode

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1414:

Labels: codec  (was: )

> heap-buffer-overflow in pni_decoder_decode_value when invoking 
> pn_message_decode
> 
>
> Key: PROTON-1414
> URL: https://issues.apache.org/jira/browse/PROTON-1414
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>  Labels: codec
> Attachments: minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba
>
>
> {noformat}
> [jdanek@e530 fuzz]$ ./fuzz-message-decode 
> minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba 
> INFO: Seed: 3671742454
> INFO: Loaded 2 modules (7259 guards): [0x7f20793b8c80, 0x7f20793bfdd4), 
> [0x74ad60, 0x74ad78), 
> ./fuzz-message-decode: Running 1 inputs 1 time(s) each.
> Running: minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba
> =
> ==29686==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x60200033 at pc 0x7f20790bf3de bp 0x7ffc0d69a970 sp 0x7ffc0d69a968
> READ of size 1 at 0x60200033 thread T0
> #0 0x7f20790bf3dd in pni_decoder_decode_value 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:389:24
> #1 0x7f20790bcfa4 in pni_decoder_single 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:477:9
> #2 0x7f20790bccc1 in pn_decoder_decode 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:491:13
> #3 0x7f20790b84c5 in pn_data_decode 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/codec.c:1437:10
> #4 0x7f207911160b in pn_message_decode 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/message.c:635:20
> #5 0x4f90c1 in LLVMFuzzerTestOneInput 
> /home/jdanek/Work/qpid-proton/proton-c/src/tests/fuzz/fuzz-message-decode.c:12:15
> #6 0x501427 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
> unsigned long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:515:13
> #7 0x501615 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned 
> long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:469:3
> #8 0x4f930c in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
> long) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:272:6
> #9 0x4fb0ac in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
> const*, unsigned long)) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:482:9
> #10 0x4f9200 in main /home/jdanek/Work/./Fuzzer/FuzzerMain.cpp:20:10
> #11 0x7f20772d2290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
> #12 0x423889 in _start 
> (/home/jdanek/Work/qpid-proton/build/proton-c/src/tests/fuzz/fuzz-message-decode+0x423889)
> 0x60200033 is located 0 bytes to the right of 3-byte region 
> [0x60200030,0x60200033)
> allocated by thread T0 here:
> #0 0x4f608b in operator new[](unsigned long) 
> (/home/jdanek/Work/qpid-proton/build/proton-c/src/tests/fuzz/fuzz-message-decode+0x4f608b)
> #1 0x50136a in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
> unsigned long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:506:23
> #2 0x501615 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned 
> long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:469:3
> #3 0x4f930c in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
> long) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:272:6
> #4 0x4fb0ac in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
> const*, unsigned long)) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:482:9
> #5 0x4f9200 in main /home/jdanek/Work/./Fuzzer/FuzzerMain.cpp:20:10
> #6 0x7f20772d2290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
> SUMMARY: AddressSanitizer: heap-buffer-overflow 
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:389:24 in 
> pni_decoder_decode_value
> Shadow bytes around the buggy address:
>   0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c047fff8000: fa fa 03 fa fa fa[03]fa fa fa 00 00 fa fa 00 00
>   0x0c047fff8010: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
>   0x0c047fff8020: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
>   0x0c047fff8030: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
>   0x0c047fff8040: fa fa 00 00 fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   

[jira] [Updated] (PROTON-1412) Add fuzzers to proton-c tests

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1412:

Labels: patch testing  (was: )

> Add fuzzers to proton-c tests
> -
>
> Key: PROTON-1412
> URL: https://issues.apache.org/jira/browse/PROTON-1412
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: proton-c
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
>  Labels: patch, testing
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Add fuzzers to proton-c test suite in order to be able to perform fuzz 
> testing of qpid-proton.
> This would then allow including qpid-proton to 
> https://github.com/google/oss-fuzz, a service that executes fuzzers for 
> opensource projects.
> I intend to propose a patch to do this today or tomorrow by cleaning up my 
> proof-of-concept 
> https://github.com/jdanekrh/qpid-proton-fuzz/tree/master/proton-c/src/tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1455) Problem building on Ubuntu xenial with g++

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1455:

Fix Version/s: proton-c-0.19.0

> Problem building on Ubuntu xenial with g++
> --
>
> Key: PROTON-1455
> URL: https://issues.apache.org/jira/browse/PROTON-1455
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build, proton-c
>Reporter: Irina Boverman
>Assignee: Justin Ross
> Fix For: proton-c-0.19.0
>
>
>  31%] Building CXX object 
> proton-c/CMakeFiles/qpid-proton.dir/src/messenger/transform.c.o
> cd /proton/build/proton-c && /usr/bin/c++  -std=c++11  -Dqpid_proton_EXPORTS 
> -I/proton/build/proton-c/src -I/proton/build/proton-c/include 
> -I/proton/proton-c/src -I/proton/proton-c/include  -fvisibility=hidden -O2 -g 
> -DNDEBUG -fPIC   -Werror -Wall -pedantic-errors -Wno-format 
> -Wno-variadic-macros   -o 
> CMakeFiles/qpid-proton.dir/src/messenger/transform.c.o -c 
> /proton/proton-c/src/messenger/transform.c
> [ 31%] Building CXX object 
> proton-c/CMakeFiles/qpid-proton.dir/src/platform/platform.c.o
> cd /proton/build/proton-c && /usr/bin/c++  -std=c++11  -Dqpid_proton_EXPORTS 
> -DUSE_ATOLL -DUSE_CLOCK_GETTIME -DUSE_STRERROR_R -I/proton/build/proton-c/src 
> -I/proton/build/proton-c/include -I/proton/proton-c/src 
> -I/proton/proton-c/include  -fvisibility=hidden -O2 -g -DNDEBUG -fPIC   
> -Werror -Wall -pedantic-errors -Wno-format -Wno-variadic-macros   -o 
> CMakeFiles/qpid-proton.dir/src/platform/platform.c.o -c 
> /proton/proton-c/src/platform/platform.c
> /proton/proton-c/src/platform/platform.c: In function 'void 
> pn_i_strerror(int, char*, size_t)':
> /proton/proton-c/src/platform/platform.c:92:34: error: ignoring return value 
> of 'char* strerror_r(int, char*, size_t)', declared with attribute 
> warn_unused_result [-Werror=unused-result]
>strerror_r(errnum, buf, buflen);
>   ^
> cc1plus: all warnings being treated as errors
> proton-c/CMakeFiles/qpid-proton.dir/build.make:1081: recipe for target 
> 'proton-c/CMakeFiles/qpid-proton.dir/src/platform/platform.c.o' failed
> make[2]: Leaving directory '/proton/build'
> make[2]: *** [proton-c/CMakeFiles/qpid-proton.dir/src/platform/platform.c.o] 
> Error 1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1365) Windows schannel code should use the transport log

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1365:

Labels: logging windows  (was: )

> Windows schannel code should use the transport log
> --
>
> Key: PROTON-1365
> URL: https://issues.apache.org/jira/browse/PROTON-1365
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.15.0
> Environment: Windows
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Minor
>  Labels: logging, windows
>
> The openssl code uses the transport log for error messages.  The Windows code 
> should do the same for consistency.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1600) Separate test infrastructure from example infrastructure

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1600:

Labels: testing  (was: )

> Separate test infrastructure from example infrastructure
> 
>
> Key: PROTON-1600
> URL: https://issues.apache.org/jira/browse/PROTON-1600
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>  Labels: testing
>
> Right now, the examples try to do both.  We can better isolate the two 
> concerns.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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: (was: proton-c-future)
   proton-j-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: proton-j-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.4.14#64029)

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

[jira] [Updated] (PROTON-727) Add a NULL-pointer checks to malloc() and realloc() calls

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-727:
---
Fix Version/s: proton-c-future

> Add a NULL-pointer checks to malloc() and realloc() calls
> -
>
> Key: PROTON-727
> URL: https://issues.apache.org/jira/browse/PROTON-727
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: German Shepherd (PrE)
>Priority: Minor
> Fix For: proton-c-future
>
>
> As we are running the ProtonC project on memory constrained systems, it is 
> possible for malloc() or realloc() to return a NULL, when there is no more 
> free heap to allocate the memory from.
> Obviously, we might have a specific optimizations in the ProtonC code, which 
> deeply minimize the amount of a total heap required, but this is not what 
> this ticket is referring to.
> In any case where there is no more free heap, or in a case where there is any 
> other issue with the allocators, the memory allocation functions return NULL.
> The ProtonC code at this state, does not check for such a situation, and it 
> always expects the malloc() and realloc() to work and to return a valid 
> pointer.
> I would like the developers to add a specific test to each place, where 
> memory allocation takes place, and to act upon an error properly (ideally - 
> with a graceful closure of the connection to broker, if possible).
> Also, a proper signalization path to the user's application (which runs the 
> ProtonC client) would be a great addition.
> If nothing fancy is planned, I would, at least, ask for adding the simple {{ 
> if (x == NULL) { do something }; }} tests to each every place where memory 
> allocation is handled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (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 closed PROTON-824.
--

Fixed way back.

> 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: 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.4.14#64029)

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

[jira] [Updated] (PROTON-198) Pkg config file installed in the wrong location on FreeBSD

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-198:
---
Labels: freebsd  (was: )

> Pkg config file installed in the wrong location on FreeBSD
> --
>
> Key: PROTON-198
> URL: https://issues.apache.org/jira/browse/PROTON-198
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.3
> Environment: FreeBSD
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>  Labels: freebsd
> Fix For: proton-c-0.19.0
>
>
> make install puts the libqpid-proton.pc file in the wrong location for the 
> platform:
> In /usr/local//pkgconfig. This platform has a seperate 
> /usr/local/libdata directory for stuff like this.
> This wouldn't be so bad if it could be configured, but currently the 
> pkgconfig directory is hardcoded to be related to the libdir.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1622) Add coverage reporting to CMake build

[Justin Ross (JIRA)]

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

Justin Ross reassigned PROTON-1622:
---

Assignee: Justin Ross

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Justin Ross
>Priority: Minor
>  Labels: patch, testing
> Fix For: proton-c-0.19.0
>
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1644:

Labels: freebsd  (was: )

> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: freebsd
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on 
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on 
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1622:

Fix Version/s: proton-c-0.19.0

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>  Labels: patch, testing
> Fix For: proton-c-0.19.0
>
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1643) [FreeBSD] ruby-example-test hangs

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1643:

Labels: freebsd  (was: )

> [FreeBSD] ruby-example-test hangs
> -
>
> Key: PROTON-1643
> URL: https://issues.apache.org/jira/browse/PROTON-1643
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: freebsd
>
> When running ctest ruby-example-test hangs.
> If you examine the process list there is a process {{/usr/local/bin/ruby23 
> reactor/broker.rb -a :26780}} that has not exited. If you kill that process 
> the test fails but the test run carries on.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1642) [Freebsd] C++ container_test hangs in test_container_stop()

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1642:

Labels: freebsd  (was: )

> [Freebsd] C++ container_test hangs in test_container_stop()
> ---
>
> Key: PROTON-1642
> URL: https://issues.apache.org/jira/browse/PROTON-1642
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Freebsd 10.3-RELEASE-p20
> libuv 1.14
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
>  Labels: freebsd
>
> Running ctest on a default build on FreeBSD 10 hangs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1622:

Component/s: (was: build)
 proton-c

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>  Labels: patch, testing
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1622:

Labels: patch testing  (was: testing)

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>  Labels: patch, testing
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1622:

Labels: testing  (was: )

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>  Labels: patch, testing
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-486) Create a User's Guide

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-486:
---
Component/s: proton-c

> Create a User's Guide
> -
>
> Key: PROTON-486
> URL: https://issues.apache.org/jira/browse/PROTON-486
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Andreas Mueller
>Assignee: Justin Ross
>  Labels: docs
>
> What would really helpful is a one-page user guide where you explain the 
> Messenger API. I want to know e.g. how to use the different QoS exactly-once, 
> at-most-once, at-least-once and all that stuff I can do with that API without 
> jumping from one header file to another and need to ask questions in mailing 
> lists. Provide basic samples with snippets in the different supported 
> language bindings.
> I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. 
> This is how our client is documented:
> http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html
> That's it. Doesn't took much effort to create it.
> Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went 
> frustrated away from it because they don't understand the basic concepts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-131) Add a engine test which validates transferring a large number of message between a receiver and sender

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-131:
---
Component/s: proton-c

> Add a engine test which validates transferring a large number of message 
> between a receiver and sender
> --
>
> Key: PROTON-131
> URL: https://issues.apache.org/jira/browse/PROTON-131
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c
>Reporter: Hiram Chirino
>Assignee: Ken Giusti
>  Labels: testing
> Fix For: proton-c-future
>
>
> Test should transfer at least 100,000 messages with a new 4k body per message 
> in both pre-settled and non-pre-settled modes.
> A test like that might have caught issues PROTON-129 and PROTON-130 earlier.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-633) pn_data_clear() doesn't clear embedded error.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-633:
---
Component/s: proton-c

> pn_data_clear() doesn't clear embedded error.
> -
>
> Key: PROTON-633
> URL: https://issues.apache.org/jira/browse/PROTON-633
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-future
>
>
> Using pn_data_clear(data) to clear the contents of data doesn't reset the 
> embedded error indicator.
> It's not clear to me if this is the correct behaviour or not.
> Is there a case for setting the error, resetting the data and then checking 
> the error status?
> I'd rather expect  to clear the data and then set the error status.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Cliff Jansen (JIRA)]

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

Cliff Jansen resolved PROTON-824.
-
Resolution: Fixed

Yes.  The last checkin should have been used as the time for resolution/close.

> 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: 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.4.14#64029)

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

[jira] [Updated] (PROTON-522) Apache Qpid Proton on Mac/OSX - C/Objective-C

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-522:
---
Component/s: proton-c

> Apache Qpid Proton on Mac/OSX - C/Objective-C
> -
>
> Key: PROTON-522
> URL: https://issues.apache.org/jira/browse/PROTON-522
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Guy Dillen
>  Labels: osx
>
> I would like using Apache Qpid Proton-C from a C or Objective-C application 
> on Mac/OSX to connect as a client to Windows Azure Service Bus.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-841) C recv example does not return disposition state

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-841:
---
Component/s: proton-c

> C recv example does not return disposition state
> 
>
> Key: PROTON-841
> URL: https://issues.apache.org/jira/browse/PROTON-841
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Matt Broadstone
>
> I apologize that I can't dig deeper into this for you, but I'm pressed for 
> time and figured it would still be meaningful feedback. I was recently 
> testing the rabbitmq amqp1.0 module against a number of amqp 1.0 clients, and 
> realized that when using the send/recv examples for the messenger api in 
> proton my recv client was disconnecting immediately after receiving a 
> message. 
> I submitted this 
> [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's 
> github and we traced the issue down to the fact that proton was not sending 
> back a state in the settled disposition frame upon receipt of the message 
> from the "send" client. The spec is incredibly ambiguous about what to do in 
> this scenario for brokers, and specifies that state is an optional field, but 
> at the same time the broker has no idea whether the message has been 
> acknowledged or rejects, simply that it has been settled. 
> Not sure how you guys want to go about this in your project, rabbitmq 
> gracefully handles this problem by closing the channel at this point (rather 
> than crashing as it did previously).
> Anyway, just letting you know!
> Cheers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1497) python program crash on send msg to queue

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1497:

Labels: crash  (was: )

> python program crash on send msg to queue
> -
>
> Key: PROTON-1497
> URL: https://issues.apache.org/jira/browse/PROTON-1497
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.17.0
> Environment: redhat 7.2 - activemq-5.14.3 - Python 3.6.0
>Reporter: Pier Paolo Panto
>  Labels: crash
> Attachments: md5.py
>
>
> In the attached file there is an on_message method that performs a lenghty 
> calculation whenever a message is receivede on the input queue. In this case, 
> the branch that gets executed is the one starting at line 123. 
> A the end of the branch a new message is created and sent so an out queue.
> The problem is that if the calculation takes a long time (>1min) to finish, 
> randomly the program crashes when trying to execute the send instruction 
>  (line 157). I also tryed to encapsulate the send into a try/except clause, 
> but the code inside the except never gets executed. 
> Moreover, the exit code (echo $?) when the program crashes is 0
> When this happens, I get this message in the log file:
> handlers.py:234 in print_error(): local-idle-timeout expired
> but setting the timeout parameters for the connection has no effect.
> What could be causing this behaviour?
> Best Regard,
> PPP



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1497) python program crash on send msg to queue

[Justin Ross (JIRA)]

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

Justin Ross reassigned PROTON-1497:
---

Assignee: Justin Ross

> python program crash on send msg to queue
> -
>
> Key: PROTON-1497
> URL: https://issues.apache.org/jira/browse/PROTON-1497
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.17.0
> Environment: redhat 7.2 - activemq-5.14.3 - Python 3.6.0
>Reporter: Pier Paolo Panto
>Assignee: Justin Ross
>  Labels: crash
> Attachments: md5.py
>
>
> In the attached file there is an on_message method that performs a lenghty 
> calculation whenever a message is receivede on the input queue. In this case, 
> the branch that gets executed is the one starting at line 123. 
> A the end of the branch a new message is created and sent so an out queue.
> The problem is that if the calculation takes a long time (>1min) to finish, 
> randomly the program crashes when trying to execute the send instruction 
>  (line 157). I also tryed to encapsulate the send into a try/except clause, 
> but the code inside the except never gets executed. 
> Moreover, the exit code (echo $?) when the program crashes is 0
> When this happens, I get this message in the log file:
> handlers.py:234 in print_error(): local-idle-timeout expired
> but setting the timeout parameters for the connection has no effect.
> What could be causing this behaviour?
> Best Regard,
> PPP



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1638) Need to improve proton-c build tree layout

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1638:

Component/s: proton-c

> Need to improve proton-c build tree layout
> --
>
> Key: PROTON-1638
> URL: https://issues.apache.org/jira/browse/PROTON-1638
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>
> The proton-c tree layout is annoying in a number of ways:
> * Since the split with proton-j there is a superfluous top level
> * CMake build flags don't propagate properly because examples are not in the 
> correct subtree
> ** Examples should be in the binding subtree that they are examples
> ** Otherwise the information for a particular binding and its examples are 
> split into 2 different parts of the proton-c tree.
> ** This means that the installation for a binding is split
> ** It is unatural in CMake to split build flags like this - CMake is 
> hierarchical



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1106) Add function implementations for pn_ssl_get_cert_fingerprint and pn_ssl_get_remote_subject_subfield for Windows

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1106:

Labels: tls windows  (was: windows)

> Add function implementations for pn_ssl_get_cert_fingerprint and 
> pn_ssl_get_remote_subject_subfield for Windows
> ---
>
> Key: PROTON-1106
> URL: https://issues.apache.org/jira/browse/PROTON-1106
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Ganesh Murthy
>Priority: Minor
>  Labels: tls, windows
> Fix For: proton-c-future
>
>
> Currently we have empty stubs for these methods in schannel.c 
> The Linux side implementation using OpenSSL is already complete. The Linux 
> implementation was done as part of PROTON-1088



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1106) Add function implementations for pn_ssl_get_cert_fingerprint and pn_ssl_get_remote_subject_subfield for Windows

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1106:

Component/s: proton-c

> Add function implementations for pn_ssl_get_cert_fingerprint and 
> pn_ssl_get_remote_subject_subfield for Windows
> ---
>
> Key: PROTON-1106
> URL: https://issues.apache.org/jira/browse/PROTON-1106
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Ganesh Murthy
>Priority: Minor
>  Labels: tls, windows
> Fix For: proton-c-future
>
>
> Currently we have empty stubs for these methods in schannel.c 
> The Linux side implementation using OpenSSL is already complete. The Linux 
> implementation was done as part of PROTON-1088



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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: security  (was: close-pending 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: 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.4.14#64029)

-
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:
---
Fix Version/s: proton-j-future

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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  (was: api close-pending)

> 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
>
> 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.4.14#64029)

-
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:   (was: close-pending)

> [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
>
> 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.4.14#64029)

-
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:
---
Issue Type: New Feature  (was: Wish)

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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: patch  (was: close-pending 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: patch
> Attachments: PROTON-186v2.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-343) Add a pluggable Proton logging layer

[Justin Ross (JIRA)]

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

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

> Add a pluggable Proton logging layer
> 
>
> Key: PROTON-343
> URL: https://issues.apache.org/jira/browse/PROTON-343
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, proton-j
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>  Labels: patch
> Attachments: 
> 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch
>
>
> Applications that use Proton sometimes want Proton to produce logging.
> Goals
> 
> * Proton should provide a default logging implementation.
> * It should be easy for Proton client code to provide custom logging 
> implementation, e.g. one that uses the same third party logging framework as 
> their application code.
> * Proton should not have a compile-time dependency on a third party logging 
> framework
> * Proton's log output is considered to be part of its public interface.  
> Therefore, in the spirit of Proton's cross-language consistency goals, this 
> output should be consistent between proton-c and proton-j.
> * The goals that general-purpose logging frameworks try to meet - 
> performance, ease of use etc - also apply.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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:   (was: close-pending)

> 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
>
> Distributed transactions should be supported with proton-j.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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: patch  (was: close-pending 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: 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.4.14#64029)

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

[jira] [Closed] (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 closed PROTON-970.
--
Resolution: Duplicate

> 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.4.14#64029)

-
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:
---
Issue Type: Improvement  (was: Bug)

> need a new message status
> -
>
> Key: PROTON-296
> URL: https://issues.apache.org/jira/browse/PROTON-296
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: michael goulish
>  Labels: api
>
> 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.4.14#64029)

-
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:
--
Issue Type: Improvement  (was: Bug)

> 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: Improvement
>  Components: proton-c
>Reporter: Ted Ross
>Priority: Minor
>  Labels: api
>
> 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.4.14#64029)

-
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  (was: api close-pending)

> need a new message status
> -
>
> Key: PROTON-296
> URL: https://issues.apache.org/jira/browse/PROTON-296
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: michael goulish
>  Labels: api
>
> 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.4.14#64029)

-
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: api close-pending)

> 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
>
> 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.4.14#64029)

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

[jira] [Closed] (PROTON-760) Improve the JavaScript binding's internal Event loop and add additional tests

[Justin Ross (JIRA)]

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

Justin Ross closed PROTON-760.
--
Resolution: Done

> Improve the JavaScript binding's internal Event loop and add additional tests
> -
>
> Key: PROTON-760
> URL: https://issues.apache.org/jira/browse/PROTON-760
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: javascript-binding
>Reporter: Fraser Adams
>  Labels: close-pending
>
> Improve the JavaScript binding's internal Event loop and add additional tests.
> The addition of JavaScript soak/performance tests msgr-send.js and 
> msgr-recv.js, which mirror tests of the same name in C and Python flagged up 
> a few edge cases that caused sporadic failures. The problems seem to be 
> related to the ws WebSocket library directly calling some callbacks rather 
> than posting to the JavaScript internal Event queue. The effect of calling 
> directly mean that the main message handler and the close handler could 
> actually get called *concurrently* which is clearly a bad thing and somewhat 
> undexpected in JavaScript. The improvements here add a number of guard 
> tests and introduce a setTimeout that allows the "real" close handler to be 
> deferred by posting it onto the Event queue.
> msgr-send and msgr-recv have been run with counts of several million messages 
> and also with message sizes of up to 2MB and everything seems stable now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-841) C recv example does not return disposition state

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-841:
---
Labels:   (was: messenger)

> C recv example does not return disposition state
> 
>
> Key: PROTON-841
> URL: https://issues.apache.org/jira/browse/PROTON-841
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Matt Broadstone
>
> I apologize that I can't dig deeper into this for you, but I'm pressed for 
> time and figured it would still be meaningful feedback. I was recently 
> testing the rabbitmq amqp1.0 module against a number of amqp 1.0 clients, and 
> realized that when using the send/recv examples for the messenger api in 
> proton my recv client was disconnecting immediately after receiving a 
> message. 
> I submitted this 
> [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's 
> github and we traced the issue down to the fact that proton was not sending 
> back a state in the settled disposition frame upon receipt of the message 
> from the "send" client. The spec is incredibly ambiguous about what to do in 
> this scenario for brokers, and specifies that state is an optional field, but 
> at the same time the broker has no idea whether the message has been 
> acknowledged or rejects, simply that it has been settled. 
> Not sure how you guys want to go about this in your project, rabbitmq 
> gracefully handles this problem by closing the channel at this point (rather 
> than crashing as it did previously).
> Anyway, just letting you know!
> Cheers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1613) Default value for Messenger::recv is -1, not 2048

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1613:

Labels: messenger patch  (was: messenger)

> Default value for Messenger::recv is -1, not 2048
> -
>
> Key: PROTON-1613
> URL: https://issues.apache.org/jira/browse/PROTON-1613
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples
>Affects Versions: 0.17.0
>Reporter: Jiri Daněk
>Priority: Trivial
>  Labels: messenger, patch
>
> {code}
> diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
> index 24bdcae7..f1353685 100755
> --- a/tests/javascript/msgr-recv.js
> +++ b/tests/javascript/msgr-recv.js
> @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
> 'function') {
>  'Usage: msgr-recv [OPTIONS]\n' +
>  ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
>  ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
> -' -b # \tArgument to Messenger::recv(n) [2048]\n' +
> +' -b # \tArgument to Messenger::recv(n) [-1]\n' +
>  ' -w # \tSize for incoming window [0]\n' +
>  ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
>  ' -R \tSend reply if \'reply-to\' present\n' +
> diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
> index eff5820c..b87f29a8 100644
> --- a/tests/tools/apps/c/msgr-recv.c
> +++ b/tests/tools/apps/c/msgr-recv.c
> @@ -52,7 +52,7 @@ static void usage(int rc)
>  printf("Usage: msgr-recv [OPTIONS] \n"
> " -a [,]* \tAddresses to listen on 
> [amqp://~0.0.0.0]\n"
> " -c # \tNumber of messages to receive before exiting 
> [0=forever]\n"
> -   " -b # \tArgument to Messenger::recv(n) [2048]\n"
> +   " -b # \tArgument to Messenger::recv(n) [-1]\n"
> " -w # \tSize for incoming window [0]\n"
> " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
> " -e # \t# seconds to report statistics, 0 = end of test [0] 
> *TBD*\n"
> diff --git a/tests/tools/apps/python/msgr-recv.py 
> b/tests/tools/apps/python/msgr-recv.py
> index 757b19c2..52fe69c3 100755
> --- a/tests/tools/apps/python/msgr-recv.py
> +++ b/tests/tools/apps/python/msgr-recv.py
> @@ -34,7 +34,7 @@ usage = """
>  Usage: msgr-recv [OPTIONS]
>   -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
>   -c # \tNumber of messages to receive before exiting [0=forever]
> - -b # \tArgument to Messenger::recv(n) [2048]
> + -b # \tArgument to Messenger::recv(n) [-1]
>   -w # \tSize for incoming window [0]
>   -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
>   -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
> {code}
> There may possibly be more discrepancies, I spotted and then was able to find 
> only this single one. The function in various bindings is usually not called 
> Messenger::recv...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-486) Create a User's Guide

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-486:
---
Labels: docs  (was: docs messenger)

> Create a User's Guide
> -
>
> Key: PROTON-486
> URL: https://issues.apache.org/jira/browse/PROTON-486
> Project: Qpid Proton
>  Issue Type: Improvement
>Reporter: Andreas Mueller
>Assignee: Justin Ross
>  Labels: docs
>
> What would really helpful is a one-page user guide where you explain the 
> Messenger API. I want to know e.g. how to use the different QoS exactly-once, 
> at-most-once, at-least-once and all that stuff I can do with that API without 
> jumping from one header file to another and need to ask questions in mailing 
> lists. Provide basic samples with snippets in the different supported 
> language bindings.
> I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. 
> This is how our client is documented:
> http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html
> That's it. Doesn't took much effort to create it.
> Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went 
> frustrated away from it because they don't understand the basic concepts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (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:comment-tabpanel=16213307#comment-16213307
 ] 

Justin Ross commented on PROTON-824:


[~cliffjansen], is this resolved?

> 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: 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.4.14#64029)

-
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: close-pending 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: 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.4.14#64029)

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

[jira] [Closed] (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 closed PROTON-889.
--
Resolution: Won't Do

> 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.4.14#64029)

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

[jira] [Commented] (QPIDIT-39) Make qpid-jms-client version a parameter of Maven build

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213281#comment-16213281
 ] 

Justin Ross commented on QPIDIT-39:
---

Cool.  [~kpvdr], would you update the status and fix version?

> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Qpid Jms Shim
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>Priority: Critical
>
> I wish to be able to change the version of qpid-jms-client library used in 
> the jms shim. This would allow running the test with older versions of the 
> library and also with various proprietary builds of the library.
> One possible way to implement this would be to make the library version a 
> maven attribute and to switch between geronimo-jms_1.1_spec and the 2.0 
> version using maven profile, e.g.:
> {noformat}
> mvn -Pjms11 -Dqpid-jms-client.version=0.11.0.mycompany-1 package
> mvn -Pjms20 -Dqpid-jms-client.version=0.20.0 package
> {noformat}
> On a related task, it might be helpful to use Maven to produce an uberjar, a 
> jar that bundles all runtime dependencies in itself. It would simplify 
> running the shim from the test program, because then there would be no 
> classpath to deal with.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPIDIT-39) Make qpid-jms-client version a parameter of Maven build

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213274#comment-16213274
 ] 

Robbie Gemmell commented on QPIDIT-39:
--

Kim did this already: 
https://github.com/apache/qpid-interop-test/blob/master/pom.xml#L56

> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Qpid Jms Shim
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>Priority: Critical
>
> I wish to be able to change the version of qpid-jms-client library used in 
> the jms shim. This would allow running the test with older versions of the 
> library and also with various proprietary builds of the library.
> One possible way to implement this would be to make the library version a 
> maven attribute and to switch between geronimo-jms_1.1_spec and the 2.0 
> version using maven profile, e.g.:
> {noformat}
> mvn -Pjms11 -Dqpid-jms-client.version=0.11.0.mycompany-1 package
> mvn -Pjms20 -Dqpid-jms-client.version=0.20.0 package
> {noformat}
> On a related task, it might be helpful to use Maven to produce an uberjar, a 
> jar that bundles all runtime dependencies in itself. It would simplify 
> running the shim from the test program, because then there would be no 
> classpath to deal with.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-859) Introduce SYSTEMD and SYSVINIT cmake switches to install files accordingly

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-859.

Resolution: Fixed

> Introduce SYSTEMD and SYSVINIT cmake switches to install files accordingly
> --
>
> Key: DISPATCH-859
> URL: https://issues.apache.org/jira/browse/DISPATCH-859
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.1.0
>
>
> Introduce two CMAKE flags SYSTEMD and SYSVINIT. Both these flags are off by 
> default. 
> If SYSTEMD is ON, install etc/qdrouterd.service
> If SYSVINIT is ON, install etc/qdrouterd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-859) Introduce SYSTEMD and SYSVINIT cmake switches to install files accordingly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213211#comment-16213211
 ] 

ASF subversion and git services commented on DISPATCH-859:
--

Commit 1dbfefa07379c2091734d7745a65547caa3a15c0 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=1dbfefa ]

DISPATCH-859 - Introduced SYSTEMD and SYSVINIT cmake switches to install files 
accordingly.


> Introduce SYSTEMD and SYSVINIT cmake switches to install files accordingly
> --
>
> Key: DISPATCH-859
> URL: https://issues.apache.org/jira/browse/DISPATCH-859
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.1.0
>
>
> Introduce two CMAKE flags SYSTEMD and SYSVINIT. Both these flags are off by 
> default. 
> If SYSTEMD is ON, install etc/qdrouterd.service
> If SYSVINIT is ON, install etc/qdrouterd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1597) Warnings when executing cmake in the examples/c directory

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1597.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.18.1

> Warnings when executing cmake in the examples/c directory
> -
>
> Key: PROTON-1597
> URL: https://issues.apache.org/jira/browse/PROTON-1597
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Irina Boverman
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.1
>
>
> docker run -it fedora:latest bash
> dnf -y update
> dnf -y install make gcc gcc-c++ cmake git valgrind swig pkgconfig doxygen 
> libuuid-devel openssl-devel python-devel python3 python3-devel ruby-devel 
> perl-devel epydoc python cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi 
> cyrus-sasl-plain cyrus-sasl-md5 rubygem-rspec rubygem-simplecov 
> rubygem-minitest rubygem-test-unit python2-tox redhat-rpm-config libuv-devel 
> libuv python-pip
>  git clone ...qpid-proton.git proton
>  cd proton
>  cmake .
>  make
>  make install
>   
> cd  /usr/local/share/proton-0.18.0/examples
> cd c
> cmake .
> RESULTS IN:
> ...
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> cmake_minimum_required(VERSION 3.9)
>   should be added at the top of the file.  The version specified may be lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Configuring done
> CMake Warning (dev) at CMakeLists.txt:41 (add_executable):
>   Policy CMP0003 should be set before this line.  Add code such as
> if(COMMAND cmake_policy)
>   cmake_policy(SET CMP0003 NEW)
> endif(COMMAND cmake_policy)
>   as early as possible but after the most recent call to
>   cmake_minimum_required or cmake_policy(VERSION).  This warning appears
>   because target "c-send" links to some libraries for which the linker must
>   search:
> -lpthread
>   and other libraries with known full path:
> /usr/local/lib64/libqpid-proton-proactor.so
>   CMake is adding directories in the second list to the linker search path in
>   case they are needed to find libraries from the first list (for backwards
>   compatibility with CMake 2.4).  Set policy CMP0003 to OLD or NEW to enable
>   or disable this behavior explicitly.  Run "cmake --help-policy CMP0003" for
>   more information.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Generating done
> -- Build files have been written to: /usr/local/share/proton-0.18.0/examples/c



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1597) Warnings when executing cmake in the examples/c directory

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1597: Add cmake_minimum_required() to examples which need to compile 
separately


> Warnings when executing cmake in the examples/c directory
> -
>
> Key: PROTON-1597
> URL: https://issues.apache.org/jira/browse/PROTON-1597
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Irina Boverman
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.1
>
>
> docker run -it fedora:latest bash
> dnf -y update
> dnf -y install make gcc gcc-c++ cmake git valgrind swig pkgconfig doxygen 
> libuuid-devel openssl-devel python-devel python3 python3-devel ruby-devel 
> perl-devel epydoc python cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi 
> cyrus-sasl-plain cyrus-sasl-md5 rubygem-rspec rubygem-simplecov 
> rubygem-minitest rubygem-test-unit python2-tox redhat-rpm-config libuv-devel 
> libuv python-pip
>  git clone ...qpid-proton.git proton
>  cd proton
>  cmake .
>  make
>  make install
>   
> cd  /usr/local/share/proton-0.18.0/examples
> cd c
> cmake .
> RESULTS IN:
> ...
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> cmake_minimum_required(VERSION 3.9)
>   should be added at the top of the file.  The version specified may be lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Configuring done
> CMake Warning (dev) at CMakeLists.txt:41 (add_executable):
>   Policy CMP0003 should be set before this line.  Add code such as
> if(COMMAND cmake_policy)
>   cmake_policy(SET CMP0003 NEW)
> endif(COMMAND cmake_policy)
>   as early as possible but after the most recent call to
>   cmake_minimum_required or cmake_policy(VERSION).  This warning appears
>   because target "c-send" links to some libraries for which the linker must
>   search:
> -lpthread
>   and other libraries with known full path:
> /usr/local/lib64/libqpid-proton-proactor.so
>   CMake is adding directories in the second list to the linker search path in
>   case they are needed to find libraries from the first list (for backwards
>   compatibility with CMake 2.4).  Set policy CMP0003 to OLD or NEW to enable
>   or disable this behavior explicitly.  Run "cmake --help-policy CMP0003" for
>   more information.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Generating done
> -- Build files have been written to: /usr/local/share/proton-0.18.0/examples/c



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-859) Introduce SYSTEMD and SYSVINIT cmake switches to install files accordingly

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-859:
--

 Summary: Introduce SYSTEMD and SYSVINIT cmake switches to install 
files accordingly
 Key: DISPATCH-859
 URL: https://issues.apache.org/jira/browse/DISPATCH-859
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Tools
Affects Versions: 1.1.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Priority: Minor
 Fix For: 1.1.0


Introduce two CMAKE flags SYSTEMD and SYSVINIT. Both these flags are off by 
default. 

If SYSTEMD is ON, install etc/qdrouterd.service
If SYSVINIT is ON, install etc/qdrouterd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1597) Warnings when executing cmake in the examples/c directory

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher reassigned PROTON-1597:
---

Assignee: Andrew Stitcher

> Warnings when executing cmake in the examples/c directory
> -
>
> Key: PROTON-1597
> URL: https://issues.apache.org/jira/browse/PROTON-1597
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Irina Boverman
>Assignee: Andrew Stitcher
>
> docker run -it fedora:latest bash
> dnf -y update
> dnf -y install make gcc gcc-c++ cmake git valgrind swig pkgconfig doxygen 
> libuuid-devel openssl-devel python-devel python3 python3-devel ruby-devel 
> perl-devel epydoc python cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi 
> cyrus-sasl-plain cyrus-sasl-md5 rubygem-rspec rubygem-simplecov 
> rubygem-minitest rubygem-test-unit python2-tox redhat-rpm-config libuv-devel 
> libuv python-pip
>  git clone ...qpid-proton.git proton
>  cd proton
>  cmake .
>  make
>  make install
>   
> cd  /usr/local/share/proton-0.18.0/examples
> cd c
> cmake .
> RESULTS IN:
> ...
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> cmake_minimum_required(VERSION 3.9)
>   should be added at the top of the file.  The version specified may be lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Configuring done
> CMake Warning (dev) at CMakeLists.txt:41 (add_executable):
>   Policy CMP0003 should be set before this line.  Add code such as
> if(COMMAND cmake_policy)
>   cmake_policy(SET CMP0003 NEW)
> endif(COMMAND cmake_policy)
>   as early as possible but after the most recent call to
>   cmake_minimum_required or cmake_policy(VERSION).  This warning appears
>   because target "c-send" links to some libraries for which the linker must
>   search:
> -lpthread
>   and other libraries with known full path:
> /usr/local/lib64/libqpid-proton-proactor.so
>   CMake is adding directories in the second list to the linker search path in
>   case they are needed to find libraries from the first list (for backwards
>   compatibility with CMake 2.4).  Set policy CMP0003 to OLD or NEW to enable
>   or disable this behavior explicitly.  Run "cmake --help-policy CMP0003" for
>   more information.
> This warning is for project developers.  Use -Wno-dev to suppress it.
> -- Generating done
> -- Build files have been written to: /usr/local/share/proton-0.18.0/examples/c



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-858) Simplify hard to follow LICENSE file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213133#comment-16213133
 ] 

ASF subversion and git services commented on DISPATCH-858:
--

Commit 651bfa74556a4ded3c16592868d3429ef52eb6ae in qpid-dispatch's branch 
refs/heads/1.0.x from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=651bfa7 ]

DISPATCH-858 - Additional fix. Add the license folder to the pom file so the 
mvn apache-rat:check can complete


> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-858) Simplify hard to follow LICENSE file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213130#comment-16213130
 ] 

ASF subversion and git services commented on DISPATCH-858:
--

Commit 392289b751f41a65dcbaca1cdaa7a00fe61e7c1e in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=392289b ]

DISPATCH-858 - Additional fix. Add the license folder to the pom file so the 
mvn apache-rat:check can complete


> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Proposed update to minimum tool requirements for proton-c

[Andrew Stitcher]

In the course of the 0.18 release process I've been looking at the
minimum build tool versions supported - specifically CMake and C/C++
compilers. I've reached the following conclusions:

We should move to a minimum supported cmake of 2.8.12.2, gcc 4.4.7 &
Visual Studio 2010.

 - The oldest Linux distributions in large scale use here seem to be
RHEL 6/CentOS 6, Ubuntu 1404, Debian 8.
   These all support either this or newer versions of cmake/gcc.

Visual Studio 2010 is already fairly old and comparable in age to gcc
4.4.7.

The benefit of this would be to simplify the CMake build system:

- Removing some early gcc specific build code
- Allowing us to use some simplifying CMake Modules
- Allow us to rely on some better cmake functions

For Visual Studio it will simplify the compilers we need to test, I'd
suggest we build/test using VS 2010, VS 2013 & VS 2017.

[VS 2010 because it's the oldest we support; VS 2013 because it
supports a pretty good subset of C99 and C++11 & VS 2017 because it is
the newest VS (with excellent C++11).]

Unless anyone objects I will do the substantive part of this next week,
before the suggested 0.18.1 release, that is:

- Update cmake_minimum() statements in the build files.
- Remove the special case code for gcc earlier than 4.4

There's nothing specific to do for VS except document that 2010 is the
earliest version that we will keep on making work.

So, thoughts, suggestions, and more particularly objections.

Andrew


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

[jira] [Commented] (PROTON-1611) cmake fails if g++ not installed

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1611: Fix that meets the high standards of aconway!


> cmake fails if g++ not installed
> 
>
> Key: PROTON-1611
> URL: https://issues.apache.org/jira/browse/PROTON-1611
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build, cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: "clean" centos docker image docker.io/centos:latest
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> While testing the 0.18 proton beta I created a stock centos docker container 
> and followed the instructions in the INSTALL.md file, installing all the 
> documented dependencies.
> cmake failed with:
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr
> CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:446 
> (execute_process):
>   execute_process given COMMAND argument with no value.
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:48 
> (CMAKE_DETERMINE_COMPILER_ID_VENDOR)
>   /usr/share/cmake/Modules/CMakeDetermineCXXCompiler.cmake:127 
> (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt:24 (enable_language)
> -- The CXX compiler identification is unknown
> -- Build type is "RelWithDebInfo" (has debug symbols)
> -- PN_VERSION: 0.18.0 (beta)
> -- Can't locate the valgrind command; no run-time error detection
> -- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE) 
> -- Building the epoll proactor
> -- Node.js (http://nodejs.org) is not installed: can't build JavaScript 
> binding
> -- Could NOT find Ruby (missing:  RUBY_EXECUTABLE RUBY_INCLUDE_DIR 
> RUBY_LIBRARY) 
> -- Could NOT find Perl (missing:  PERL_EXECUTABLE) 
> -- Could NOT find Perl (missing:  PERL_EXECUTABLE) 
> -- Could NOT find PerlLibs (missing:  PERL_LIBRARY PERL_INCLUDE_PATH) 
> -- Trying alternative search for Perl
> -- Looking for 
> -- No Perl devel environment found - skipping Perl bindings
> -- The tox tool is not available; skipping the python-tox-tests
> -- Configuring incomplete, errors occurred!
> See also "/root/qpid-proton-0.18.0-beta/BUILD/CMakeFiles/CMakeOutput.log".
> See also "/root/qpid-proton-0.18.0-beta/BUILD/CMakeFiles/CMakeError.log".
> Had to ' yum install gcc-c++' in order to get cmake generation to succeed. 
> Either the INSTALL.md needs to list gcc-c++ for a required dep, or the cmake 
> scripts need to avoid building the c++ binding if no c++ compiler is 
> installed.
> Did not test but suspect ubuntu build may fail in a similar fashion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1633) Windows Link warnings due to unnecessary command line flags

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1633: Much neater way to allow the examples to work with the sanitizers


> Windows Link warnings due to unnecessary command line flags
> ---
>
> Key: PROTON-1633
> URL: https://issues.apache.org/jira/browse/PROTON-1633
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: Visual Studio
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> We are explicitly putting compile flags on the link line and this is 
> generating pointless and distracting warnings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-855) Router crash when disconnecting from console

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-855.

   Resolution: Fixed
Fix Version/s: 1.0.0

This issue cannot be reproduced in the 1.0.x or master branches.

> Router crash when disconnecting from console
> 
>
> Key: DISPATCH-855
> URL: https://issues.apache.org/jira/browse/DISPATCH-855
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
> Fix For: 1.0.0
>
>
> The router will crash if it receives a connection from a console and then the 
> console disconnects.
> To reproduce:
> - dnf install qpid-dispatch-router
> - dnf install qpid-dispatch-tools
> - create a config file with an http listener named A.conf that contains:
> router {
> mode: standalone
> id: A
> }
> listener {
> port: 5673
> host: 0.0.0.0
> http: true
> saslMechanisms: ANONYMOUS
> name: Console Listener
> }
> - start the router
> $ qdrouterd --config A.conf
> - connect a console: browse to localhost:5673
> - close the browser window
> - the router crashes
> Here is the output from the router:
> qdrouterd --config /usr/local/etc/qpid-dispatch/A.conf 
> 2017-10-10 13:37:20.279849 -0400 SERVER (info) Container Name: A
> 2017-10-10 13:37:20.279926 -0400 ROUTER (info) Router started in Standalone 
> mode
> 2017-10-10 13:37:20.280273 -0400 ROUTER_CORE (info) Router Core thread 
> running. 0/A
> 2017-10-10 13:37:20.280290 -0400 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-10-10 13:37:20.333194 -0400 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-10-10 13:37:20.333276 -0400 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-10-10 13:37:20.10 -0400 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-10-10 13:37:20.333608 -0400 CONN_MGR (info) Configured Listener: 
> localhost:5673 proto=any, role=normal, http
> 2017-10-10 13:37:20.333725 -0400 SERVER (info) HTTP server thread running
> 2017-10-10 13:37:20.333825 -0400 SERVER (notice) Listening for HTTP on 
> localhost:5673
> 2017-10-10 13:37:20.336628 -0400 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-10-10 13:37:20.341923 -0400 POLICY (info) Policy fallback defaultVhost 
> is defined: '$default'
> 2017-10-10 13:37:20.342088 -0400 SERVER (info) Operational, 4 Threads Running
> 2017-10-10 13:37:57.114258 -0400 CONTAINER (notice) Aborting link 
> '68c3979a-9bdf-7e4e-b578-ecfcd8925acb' due to parent connection end
> 2017-10-10 13:37:57.114304 -0400 CONTAINER (notice) Aborting link 
> '5ec6b95c-3885-984e-995d-297f2841ca02' due to parent connection end
> Segmentation fault (core dumped)
> Here is a backtrace:
> (gdb) bt
> #0  0x0010 in ?? ()
> #1  0x779379fe in pn_class_decref (clazz=0x7fffe4019b60, 
> clazz@entry=0x77b6ec00 , object=0x7fffe4019b40)
> at /usr/src/debug/qpid-proton-0.17.0/proton-c/src/core/object/object.c:91
> #2  0x77937c2f in pn_decref (object=)
> at /usr/src/debug/qpid-proton-0.17.0/proton-c/src/core/object/object.c:253
> #3  0x77944732 in pn_collector_free (collector=)
> at /usr/src/debug/qpid-proton-0.17.0/proton-c/src/core/event.c:108
> #4  0x77bb6bcc in qd_connection_free (ctx=0x7fffe400c290)
> at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:169
> #5  0x77bbaa21 in callback_amqpws (wsi=0x7fffe400a640, 
> reason=, user=0x7fffe400a850, in=0x0, len=0)
> at /usr/src/debug/qpid-dispatch-0.8.0/src/http-libwebsockets.c:496
> #6  0x76cffe6c in lws_close_free_wsi (wsi=wsi@entry=0x7fffe400a640, 
> reason=reason@entry=LWS_CLOSE_STATUS_NOSTATUS)
> at /usr/src/debug/libwebsockets-2.1.1/lib/libwebsockets.c:518
> #7  0x76d0179e in lws_service_fd_tsi (
> context=context@entry=0x559e08d0, pollfd=, 
> tsi=tsi@entry=0) at /usr/src/debug/libwebsockets-2.1.1/lib/service.c:1117
> #8  0x76d0bc73 in lws_plat_service_tsi (context=0x559e08d0, 
> timeout_ms=, tsi=tsi@entry=0)
> at /usr/src/debug/libwebsockets-2.1.1/lib/lws-plat-unix.c:184
> #9  0x76d0be47 in lws_plat_service (context=, 
> timeout_ms=)
> at /usr/src/debug/libwebsockets-2.1.1/lib/lws-plat-unix.c:204
> #10 0x76d01d55 in lws_service (context=, 
> timeout_ms=)
> at /usr/src/debug/libwebsockets-2.1.1/lib/service.c:1139
> #11 0x77bbb76c in http_thread_run (v=0x559f45f0)
> at /usr/src/debug/qpid-dispatch-0.8.0/src/http-libwebsockets.c:536
> #12 0x7770e6ca in start_thread () from /lib64/libpthread.so.0
> #13 0x76a39f7f in clone () from /lib64/libc.so.6
> Notes:
> $ rpm -qa | grep dispatch
> 

[jira] [Updated] (QPIDIT-85) Tests don't limit the number of times it tries to connect to a broker

[Justin Ross (JIRA)]

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

Justin Ross updated QPIDIT-85:
--
Priority: Minor  (was: Major)

> Tests don't limit the number of times it tries to connect to a broker
> -
>
> Key: QPIDIT-85
> URL: https://issues.apache.org/jira/browse/QPIDIT-85
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
>
> When no broker is present, or when a misconfiguration prevents communication 
> to the broker, then the test keeps attempting to connect without time or 
> number limit:
> {noformat}
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ...
> {noformat}
> and will keep trying indefinitely, effectively hanging the test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPIDIT-79) Stopping Python tests using ctrl+c sometimes results in a zombie shim

[Justin Ross (JIRA)]

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

Justin Ross updated QPIDIT-79:
--
Labels: gotcha  (was: )

> Stopping Python tests using ctrl+c sometimes results in a zombie shim
> -
>
> Key: QPIDIT-79
> URL: https://issues.apache.org/jira/browse/QPIDIT-79
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>  Labels: gotcha
>
> When interrupting some tests (particularly Python tests) using ctrl+c will 
> stop the test, but will sometimes leave a zombie process behind (either a 
> Sender or a Receiver process).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPIDIT-78) Add AMQP local transaction test

[Justin Ross (JIRA)]

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

Justin Ross updated QPIDIT-78:
--
Priority: Minor  (was: Major)

> Add AMQP local transaction test
> ---
>
> Key: QPIDIT-78
> URL: https://issues.apache.org/jira/browse/QPIDIT-78
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
>
> Add an AMQP local transaction test. This will test a local transaction where 
> the scope of the transaction will be limited to a single client. Multiple 
> actions may be performed on multiple queues and need to comply with the 
> atomic constraints imposed by the transaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPIDIT-89) Detecting failed shims without elapsing full timeout

[Justin Ross (JIRA)]

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

Justin Ross reassigned QPIDIT-89:
-

Assignee: Kim van der Riet

> Detecting failed shims without elapsing full timeout
> 
>
> Key: QPIDIT-89
> URL: https://issues.apache.org/jira/browse/QPIDIT-89
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>
> If a test has a sender that throws but a receiver that does not then the test 
> may elapse the full timeout period before failing.
> What are the rules for a sender throwing an exception so that it is seen by 
> the test runner?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPIDIT-89) Detecting failed shims without elapsing full timeout

[Justin Ross (JIRA)]

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

Justin Ross updated QPIDIT-89:
--
Priority: Minor  (was: Major)

> Detecting failed shims without elapsing full timeout
> 
>
> Key: QPIDIT-89
> URL: https://issues.apache.org/jira/browse/QPIDIT-89
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Minor
>
> If a test has a sender that throws but a receiver that does not then the test 
> may elapse the full timeout period before failing.
> What are the rules for a sender throwing an exception so that it is seen by 
> the test runner?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPIDIT-93) Optionally produce xUnit XML report with test results

[Justin Ross (JIRA)]

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

Justin Ross reassigned QPIDIT-93:
-

Assignee: Kim van der Riet

> Optionally produce xUnit XML report with test results
> -
>
> Key: QPIDIT-93
> URL: https://issues.apache.org/jira/browse/QPIDIT-93
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>Affects Versions: 0.1.0-SNAPSHOT
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>
> Something like the following should do the job. Instead of 
> https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
> maybe switch from unittest package to py.test, which has xUnit reports built 
> in.
> {noformat}
> diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
> b/src/python/qpid_interop_test/jms_messages_test.py
> index 3b54510..3b94f3a 100755
> --- a/src/python/qpid_interop_test/jms_messages_test.py
> +++ b/src/python/qpid_interop_test/jms_messages_test.py
> @@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
>  from json import dumps
>  from os import getenv, path
> +import xmlrunner
>  from proton import symbol
>  from qpid_interop_test.test_type_map import TestTypeMap
> @@ -302,7 +300,7 @@ class TestOptions(object):
>  Class controlling command-line arguments used to control the test.
>  """
>  def __init__(self, shim_map):
> -parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoparability test suite '
> +parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoperability test suite '
>   'for JMS message types')
>  parser.add_argument('--sender', action='store', 
> default='localhost:5672', metavar='IP-ADDR:PORT',
>  help='Node to which test suite will send 
> messages.')
> @@ -313,6 +311,8 @@ class TestOptions(object):
>  parser.add_argument('--broker-type', action='store', 
> metavar='BROKER_NAME',
>  help='Disable test of broker type (using 
> connection properties) by specifying the broker' +
>  ' name, or "None".')
> +parser.add_argument('--xunit-report-dir', action='store', 
> metavar='REPORTS_DIRECTORY',
> +help='Generate xUnit report into 
> REPORTS_DIRECTORY/TEST--.xml')
>  type_group = parser.add_mutually_exclusive_group()
>  type_group.add_argument('--include-type', action='append', 
> metavar='JMS_MESSAGE-TYPE',
>  help='Name of JMS message type to include. 
> Supported types:\n%s' %
> @@ -421,6 +421,7 @@ if __name__ == '__main__':
>  TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
>  
>  # Finally, run all the dynamically created tests
> -RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
> +#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
> +RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
>  if not RES.wasSuccessful():
>  sys.exit(1)
> {noformat}
> The main "problem" seems that each test has completely separate main method 
> and builds up options from scratch. Adding this to every test would mean some 
> unnecessary duplication. So maybe refactor this somewhat at first? On the 
> other hand, there are good reasons to keep the tests simple...
> What do you think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPIDIT-39) Make qpid-jms-client version a parameter of Maven build

[Kim van der Riet (JIRA)]

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

Kim van der Riet reassigned QPIDIT-39:
--

Assignee: Kim van der Riet

> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Qpid Jms Shim
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>Priority: Critical
>
> I wish to be able to change the version of qpid-jms-client library used in 
> the jms shim. This would allow running the test with older versions of the 
> library and also with various proprietary builds of the library.
> One possible way to implement this would be to make the library version a 
> maven attribute and to switch between geronimo-jms_1.1_spec and the 2.0 
> version using maven profile, e.g.:
> {noformat}
> mvn -Pjms11 -Dqpid-jms-client.version=0.11.0.mycompany-1 package
> mvn -Pjms20 -Dqpid-jms-client.version=0.20.0 package
> {noformat}
> On a related task, it might be helpful to use Maven to produce an uberjar, a 
> jar that bundles all runtime dependencies in itself. It would simplify 
> running the shim from the test program, because then there would be no 
> classpath to deal with.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPIDIT-39) Make qpid-jms-client version a parameter of Maven build

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213022#comment-16213022
 ] 

Justin Ross commented on QPIDIT-39:
---

https://github.com/ssorj/quiver/blob/master/java/pom.xml#L46

> Make qpid-jms-client version a parameter of Maven build
> ---
>
> Key: QPIDIT-39
> URL: https://issues.apache.org/jira/browse/QPIDIT-39
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Qpid Jms Shim
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>Priority: Critical
>
> I wish to be able to change the version of qpid-jms-client library used in 
> the jms shim. This would allow running the test with older versions of the 
> library and also with various proprietary builds of the library.
> One possible way to implement this would be to make the library version a 
> maven attribute and to switch between geronimo-jms_1.1_spec and the 2.0 
> version using maven profile, e.g.:
> {noformat}
> mvn -Pjms11 -Dqpid-jms-client.version=0.11.0.mycompany-1 package
> mvn -Pjms20 -Dqpid-jms-client.version=0.20.0 package
> {noformat}
> On a related task, it might be helpful to use Maven to produce an uberjar, a 
> jar that bundles all runtime dependencies in itself. It would simplify 
> running the shim from the test program, because then there would be no 
> classpath to deal with.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Set CGO_LDFLAGS and CGO_CFLAGS on Windows 10 to install electron with golang

[Alessio Gottardo]

Hi,
I wanted to use the electron package for golang so I went here: 
https://github.com/apache/qpid-proton/tree/master/examples/go where it is said 
that I need to compile the proton-C library.
I cloned that project with: "git clone https://github.com/apache/qpid-proton;
I followed the steps here: 
https://github.com/apache/qpid-proton/blob/master/INSTALL.md- I installed CMake 
from their websites and used it with its full path (the cmake from Cygwin was 
not finding stuff related to C++ compilers and/or environment variables but 
from the output I've seen it was trying to compile this project using GCC)- I 
run this command from powershell from within the "build" directory: "& 
'C:\Program Files\CMake\bin\cmake.exe' .."- I used the "swig" command provided 
by Cygwin (it's in the PATH).- I have to mention that when installing Visual 
Studio 2017 I included the CMake tools as explained in here: 
https://stackoverflow.com/a/46518629/1264920- I opened Visual Studio as an 
administrator and I opened the ALL_BUILD project, then I clicked Build > Build 
ALL_BUILD. The output from the console seems to prove I've successfully built 
this project e.g. saying at the end "== Build: 58 succeeded, 0 failed, 
0 up-to-date, 0 skipped =="
I went back to the electron docs where it is said to run "go get 
qpid.apache.org/electron" with a couple of environment variables that from my 
understanding should point to somewhere inside the "build" directory I've used 
to compile the code with Visual Studio.
I tried using Cygwin to export one of the 2 variables like this: export 
CGO_CFLAGS="-IC:\Users\\\qpid-proton\build\proton-c"However 
the "go get" command keeps complaining it does not find this header file: 
"proton/error.h"I searched for that header file but in the "build" directory 
there is not such file.There is one header file "version.h" in 
\qpid-proton\build\proton-c/include/proton/ though (I am not sure this 
is relevant).Also: I don't know how to set the CGO_LDFLAGS environment variable 
because in the "build" directory I can not find the "lib" directory that is 
mentioned in the docs.
How can I install this electron golang package on Windows?Is the build 
procedure on Visual Studio enough to assume I've built qpid-proton? If yes, 
then where are these header files that I can not find when inspecting the file 
system?
Thank youAlessio

[jira] [Updated] (PROTON-1639) proton.c ipv6 test does not detect lack of ipv6 support

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1639:
---
Fix Version/s: proton-c-0.18.1

> proton.c ipv6 test does not detect lack of ipv6 support
> ---
>
> Key: PROTON-1639
> URL: https://issues.apache.org/jira/browse/PROTON-1639
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0, proton-c-0.18.1
>
>
> This test tries to listen on the ipv6 "::" undefined address, and expects 
> that to fail if ipv6 is not supported, in which case it skips the remaining 
> ipv6 tests. However this has been broken at some point as the listen attempt 
> claims to succeed even if ipv6 has been disabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

[Alan Conway (JIRA)]

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

Alan Conway closed PROTON-1592.
---
Resolution: Won't Fix

The issue is due to the unfinished status of the transaction API. Until we 
clarify and finalize that behavior there is some danger of changes. The example 
has been fixed to work before and after the change, which is the best we can do 
for now.

> [proton-python] accessing properties of event.receiver in on_link_opened 
> throws exception
> -
>
> Key: PROTON-1592
> URL: https://issues.apache.org/jira/browse/PROTON-1592
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>  Labels: regression
> Fix For: proton-c-0.18.0
>
>
> Apply the following patch to the {{tx-recv.py}} example
> {code}
> diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
> index 4baddcf5..54f3b489 100755
> --- a/examples/python/tx_recv.py
> +++ b/examples/python/tx_recv.py
> @@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
>  self.container.declare_transaction(self.conn, handler=self)
>  self.transaction = None
>  
> + def on_link_opened(self, event):
> + event.receiver.drain_mode = True
> +
>  def on_message(self, event):
>  print(event.message.body)
>  self.transaction.accept(event.delivery)
> {code}
> Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
> throws exception
> {noformat}
> $ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
> python ../examples/python/tx_recv.py
> Traceback (most recent call last):
>   File "../examples/python/tx_recv.py", line 79, in 
> Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 4068, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3857, in dispatch
> return handler.on_unhandled(method, *args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 876, in on_unhandled
> event.dispatch(handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3980, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 298, in on_link_remote_open
> self.on_link_opened(event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 313, in on_link_opened
> dispatch(self.delegate, 'on_link_opened', event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File "../examples/python/tx_recv.py", line 44, in on_link_opened
> event.receiver.drain_mode = True
> AttributeError: 'NoneType' object has no attribute 'drain_mode'
> {noformat}
> To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
> Pypi. With this previous release, there is success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1639) proton.c ipv6 test does not detect lack of ipv6 support

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1639.
-
   Resolution: Fixed
Fix Version/s: (was: proton-c-0.18.0)
   proton-c-0.19.0

> proton.c ipv6 test does not detect lack of ipv6 support
> ---
>
> Key: PROTON-1639
> URL: https://issues.apache.org/jira/browse/PROTON-1639
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> This test tries to listen on the ipv6 "::" undefined address, and expects 
> that to fail if ipv6 is not supported, in which case it skips the remaining 
> ipv6 tests. However this has been broken at some point as the listen attempt 
> claims to succeed even if ipv6 has been disabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1644:
-

I think the "use existing socket" in PROTON-1646 is the right way to solve this 
problem, since it also has legitimate use-cases outside of testing.

> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on 
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on 
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1645) Building go binding with libuv fails

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1645:
-

Agreed. There are annoying problems both ways but I think I will switch it back 
to building in the build tree as this also causes problems with simultaneously 
building multiple build trees, as they compete to build in the same go output 
directory.

> Building go binding with libuv fails
> 
>
> Key: PROTON-1645
> URL: https://issues.apache.org/jira/browse/PROTON-1645
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: proton-c-0.18.0
> Environment: Fedora 25, go 1.7.6, libuv 1.10.2
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>
> When proton-c is built with the libuv proactor the go binding build fails to 
> link with:
> {noformat}
> [3/7] cd /home/andrew/Work/proton/bld-libuv && 
> /...rew/Work/proton/src/examples/go/proton/broker.go
> FAILED: examples/go/CMakeFiles/go_example_proton_broker 
> cd /home/andrew/Work/proton/bld-libuv && /usr/bin/python 
> /home/andrew/Work/proton/src/proton-c/env.py -- 
> GOPATH=/home/andrew/Work/proton/src/proton-c/bindings/go 
> CGO_CFLAGS=-I/home/andrew/Work/proton/src/proton-c/include\ 
> -I/home/andrew/Work/proton/bld-libuv/proton-c/include 
> CGO_LDFLAGS=-L/home/andrew/Work/proton/bld-libuv/proton-c 
> PN_INTEROP_DIR=/home/andrew/Work/proton/src/tests/interop /usr/bin/go build 
> -ldflags -r\ /home/andrew/Work/proton/bld-libuv/proton-c -o 
> /home/andrew/Work/proton/bld-libuv/examples/go/proton/broker 
> /home/andrew/Work/proton/src/examples/go/proton/broker.go
> # command-line-arguments
> /usr/lib/golang/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
> /usr/bin/ld: cannot find -lqpid-proton-core
> /usr/bin/ld: cannot find -lqpid-proton-core
> /usr/bin/ld: cannot find -lqpid-proton-core
> collect2: error: ld returned 1 exit status
> {noformat}
> From the error message it looks like go should have been passed the absolute 
> path to {{libqpid-proton-core.so}} rather than just -lqpid-proton-core.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [jira] [Commented] (PROTON-1646) Proactor API needs a way to use an existing socket.

[Alan Conway]

+1 to using an existing socket, it's more flexible than listen(0) + report
as per the inetd case. qpidd started out doing listen(0) + report and we
ended up having to do the existing socket thing as well - just existing
socket covers both with less code in the proactor.

On Fri, Oct 20, 2017 at 3:29 PM, Robbie Gemmell (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/PROTON-1646?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16212712#comment-16212712 ]
>
> Robbie Gemmell commented on PROTON-1646:
> 
>
> Another common approach for tests can be for a component to be told to
> bind a free port by itself, with it then offering a way to find out what it
> was.
>
> > Proactor API needs a way to use an existing socket.
> > ---
> >
> > Key: PROTON-1646
> > URL: https://issues.apache.org/jira/browse/PROTON-1646
> > Project: Qpid Proton
> >  Issue Type: Improvement
> >  Components: cpp-binding, proton-c
> >Affects Versions: proton-c-0.18.0
> >Reporter: Andrew Stitcher
> >Assignee: Cliff Jansen
> >
> > There are various times when it is necessary to take an existing socket
> and use it to communicate.
> > * The most obvious is when we are started by systemd or inetd and passed
> the listening socket that they have accepted on our behalf.
> > * Another case is in tests when we might want to open a port using a
> random port number and then atomically hand that to test code.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

[jira] [Updated] (PROTON-1647) [go] support for crypto.tls connections

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1647:

Description: 
The electron and proton Go bindings do not expose proton's built-in SSL layer 
because Go provides it's own TLS layer in the crypto.tls package which is more 
portable, capable and familiar to Go programmers.

You can already use a tls.Conn with proton or electron, but there are several 
points that should be cleaned up:

- when a TLS connection is in use set allow-insecure-mechs in proton-C 
automatically
- make sure the AMQP virtual-host matches the TLS virtual-host by default
- provide access to the net.Conn used by an electron.Connection, which in turn 
will give access to TLS details if the user needs them
- provide an example of using TLS (maybe with SASL PLAIN auth?)


  was:
The electron and proton Go bindings do not expose proton's built-in SSL layer 
because Go provides it's own TLS layer in the crypto.tls package which is more 
portable, capable and familiar to Go programmers.

You can already use a tls.Conn with proton or electron, but there are several 
points that should be cleaned up:

- when a TLS connection is in use set allow-insecure-mechs in proton-C 
automatically
- make sure the AMQP virtual-host matches the TLS virtual-host by default
- provide an example of using TLS (maybe wit SASL PLAIN auth?)



> [go] support for crypto.tls connections
> ---
>
> Key: PROTON-1647
> URL: https://issues.apache.org/jira/browse/PROTON-1647
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The electron and proton Go bindings do not expose proton's built-in SSL layer 
> because Go provides it's own TLS layer in the crypto.tls package which is 
> more portable, capable and familiar to Go programmers.
> You can already use a tls.Conn with proton or electron, but there are several 
> points that should be cleaned up:
> - when a TLS connection is in use set allow-insecure-mechs in proton-C 
> automatically
> - make sure the AMQP virtual-host matches the TLS virtual-host by default
> - provide access to the net.Conn used by an electron.Connection, which in 
> turn will give access to TLS details if the user needs them
> - provide an example of using TLS (maybe with SASL PLAIN auth?)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1647) [go] support for crypto.tls connections

[Alan Conway (JIRA)]

Alan Conway created PROTON-1647:
---

 Summary: [go] support for crypto.tls connections
 Key: PROTON-1647
 URL: https://issues.apache.org/jira/browse/PROTON-1647
 Project: Qpid Proton
  Issue Type: Bug
  Components: go-binding
Affects Versions: proton-c-0.18.0
Reporter: Alan Conway
Assignee: Alan Conway


The electron and proton Go bindings do not expose proton's built-in SSL layer 
because Go provides it's own TLS layer in the crypto.tls package which is more 
portable, capable and familiar to Go programmers.

You can already use a tls.Conn with proton or electron, but there are several 
points that should be cleaned up:

- when a TLS connection is in use set allow-insecure-mechs in proton-C 
automatically
- make sure the AMQP virtual-host matches the TLS virtual-host by default
- provide an example of using TLS (maybe wit SASL PLAIN auth?)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7832) Refactor store/protocol API using Collection

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7832:
-
Attachment: 0002-QPID-7832-Java-Broker-Improve-performance-for-QpidBy.patch

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> .0001-QPID-7832-Java-Broker-Small-performance-optimisation.patch.swp, 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch, 
> 0002-QPID-7832-Java-Broker-Improve-performance-for-QpidBy.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7832) Refactor store/protocol API using Collection

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7832:
-
Attachment: 
.0001-QPID-7832-Java-Broker-Small-performance-optimisation.patch.swp

> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> .0001-QPID-7832-Java-Broker-Small-performance-optimisation.patch.swp, 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7832) Refactor store/protocol API using Collection

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212776#comment-16212776
 ] 

ASF subversion and git services commented on QPID-7832:
---

Commit 000228a5ac3a38043d5e6ddb153a45449fa5efdb in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=000228a ]

QPID-7832: [Java Broker] Change type of QpidByteBuffer#_fragments from List to 
array


> Refactor store/protocol API using Collection
> -
>
> Key: QPID-7832
> URL: https://issues.apache.org/jira/browse/QPID-7832
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch
>
>
> Store/protocol APIs have gradually been evolving to accept/return message 
> content/message metadata in terms of an ordered list of QBBs.  This has lead 
> to use of helper methods such as those in QBBUtils which read from a list of 
> buffers rather than a single one.
> This would be better refactored.   QpidByteBuffer should be an interface.  
> This would allow a concrete implementation CompositeQpidByteBuffer which is 
> backed by a list produced by the store or network IO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[JIRA]

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

Jiri Daněk updated PROTON-1622:
---
Priority: Minor  (was: Major)

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1646) Proactor API needs a way to use an existing socket.

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on PROTON-1646:


Another common approach for tests can be for a component to be told to bind a 
free port by itself, with it then offering a way to find out what it was.

> Proactor API needs a way to use an existing socket.
> ---
>
> Key: PROTON-1646
> URL: https://issues.apache.org/jira/browse/PROTON-1646
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
>
> There are various times when it is necessary to take an existing socket and 
> use it to communicate.
> * The most obvious is when we are started by systemd or inetd and passed the 
> listening socket that they have accepted on our behalf.
> * Another case is in tests when we might want to open a port using a random 
> port number and then atomically hand that to test code. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1622) Add coverage reporting to CMake build

[JIRA]

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

Jiri Daněk updated PROTON-1622:
---
Flags: Patch

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (PROTON-1622) Add coverage reporting to CMake build

[JIRA]

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

Jiri Daněk edited comment on PROTON-1622 at 10/20/17 2:27 PM:
--

PR is https://github.com/apache/qpid-proton/pull/124 (I put wrong Jira number 
to commit originally, so it did not link automatically)


was (Author: jdanek):
PR is https://github.com/apache/qpid-proton/pull/124 (I put wrong Jira number 
to commit, so it did not link automatically)

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1622) Add coverage reporting to CMake build

[JIRA]

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

Jiri Daněk commented on PROTON-1622:


PR is https://github.com/apache/qpid-proton/pull/124 (I put wrong Jira number 
to commit, so it did not link automatically)

> Add coverage reporting to CMake build
> -
>
> Key: PROTON-1622
> URL: https://issues.apache.org/jira/browse/PROTON-1622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>
> This improvement is intended to cover
> * Reporting coverage from Python code
> * Upload of Python and C/C++ coverage data from Travis CI to codecov.io for 
> easy viewing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

[JIRA]

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

Jiri Daněk edited comment on PROTON-1592 at 10/20/17 2:25 PM:
--

[~justi9], [~gsim] This was fixed how, exactly? As far as I can tell the issue 
is still there in the RC1 release that is being voted on.


was (Author: jdanek):
[~justi9] This was fixed how, exactly? As far as I can tell the issue is still 
there in the RC1 release that is being voted on.

> [proton-python] accessing properties of event.receiver in on_link_opened 
> throws exception
> -
>
> Key: PROTON-1592
> URL: https://issues.apache.org/jira/browse/PROTON-1592
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>  Labels: regression
> Fix For: proton-c-0.18.0
>
>
> Apply the following patch to the {{tx-recv.py}} example
> {code}
> diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
> index 4baddcf5..54f3b489 100755
> --- a/examples/python/tx_recv.py
> +++ b/examples/python/tx_recv.py
> @@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
>  self.container.declare_transaction(self.conn, handler=self)
>  self.transaction = None
>  
> + def on_link_opened(self, event):
> + event.receiver.drain_mode = True
> +
>  def on_message(self, event):
>  print(event.message.body)
>  self.transaction.accept(event.delivery)
> {code}
> Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
> throws exception
> {noformat}
> $ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
> python ../examples/python/tx_recv.py
> Traceback (most recent call last):
>   File "../examples/python/tx_recv.py", line 79, in 
> Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 4068, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3857, in dispatch
> return handler.on_unhandled(method, *args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 876, in on_unhandled
> event.dispatch(handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3980, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 298, in on_link_remote_open
> self.on_link_opened(event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 313, in on_link_opened
> dispatch(self.delegate, 'on_link_opened', event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File "../examples/python/tx_recv.py", line 44, in on_link_opened
> event.receiver.drain_mode = True
> AttributeError: 'NoneType' object has no attribute 'drain_mode'
> {noformat}
> To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
> Pypi. With this previous release, there is success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

[JIRA]

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

Jiri Daněk reopened PROTON-1592:


[~justi9] This was fixed how, exactly? As far as I can tell the issue is still 
there in the RC1 release that is being voted on.

> [proton-python] accessing properties of event.receiver in on_link_opened 
> throws exception
> -
>
> Key: PROTON-1592
> URL: https://issues.apache.org/jira/browse/PROTON-1592
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>  Labels: regression
> Fix For: proton-c-0.18.0
>
>
> Apply the following patch to the {{tx-recv.py}} example
> {code}
> diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
> index 4baddcf5..54f3b489 100755
> --- a/examples/python/tx_recv.py
> +++ b/examples/python/tx_recv.py
> @@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
>  self.container.declare_transaction(self.conn, handler=self)
>  self.transaction = None
>  
> + def on_link_opened(self, event):
> + event.receiver.drain_mode = True
> +
>  def on_message(self, event):
>  print(event.message.body)
>  self.transaction.accept(event.delivery)
> {code}
> Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
> throws exception
> {noformat}
> $ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
> python ../examples/python/tx_recv.py
> Traceback (most recent call last):
>   File "../examples/python/tx_recv.py", line 79, in 
> Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 4068, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3857, in dispatch
> return handler.on_unhandled(method, *args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 876, in on_unhandled
> event.dispatch(handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3980, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 298, in on_link_remote_open
> self.on_link_opened(event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 313, in on_link_opened
> dispatch(self.delegate, 'on_link_opened', event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File "../examples/python/tx_recv.py", line 44, in on_link_opened
> event.receiver.drain_mode = True
> AttributeError: 'NoneType' object has no attribute 'drain_mode'
> {noformat}
> To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
> Pypi. With this previous release, there is success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-858) Simplify hard to follow LICENSE file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212692#comment-16212692
 ] 

ASF subversion and git services commented on DISPATCH-858:
--

Commit 95a667dc8f7cdbf0ae13b2ebfdefb1b6297d215a in qpid-dispatch's branch 
refs/heads/1.0.x from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=95a667d ]

DISPATCH-858 - Moved third party text into files and point to these files from 
the LICENSE file. This closes #212


> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-858) Simplify hard to follow LICENSE file

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-858.

   Resolution: Fixed
Fix Version/s: 1.0.0

> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-858) Simplify hard to follow LICENSE file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212668#comment-16212668
 ] 

ASF GitHub Bot commented on DISPATCH-858:
-

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/212


> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-858) Simplify hard to follow LICENSE file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212666#comment-16212666
 ] 

ASF subversion and git services commented on DISPATCH-858:
--

Commit a71ff5c9613b4b408956a72fad1309c205b71088 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a71ff5c ]

DISPATCH-858 - Moved third party text into files and point to these files from 
the LICENSE file. This closes #212


> Simplify hard to follow LICENSE file
> 
>
> Key: DISPATCH-858
> URL: https://issues.apache.org/jira/browse/DISPATCH-858
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
>
> The LICENSE file is pretty large and not as clear as it could be when trying 
> to figure out which
> bits apply to what and whether certain statements are sub-parts of
> licence text referring to bits of their respective projects (that we
> might not even include) as opposed to general statements about
> Dispatch files. 
> Move third party text into files and point to these files from the LICENSE 
> file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1639) proton.c ipv6 test does not detect lack of ipv6 support

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1639 proton.c ipv6 test does not detect lack of ipv6 support

The test was checking for IPV6 by listening on "::" INADDR6_ANY.

On some IPV6-capable platforms with IPV6 disabled, this listen() succeeds even
though it not possible to connect to the listening port.

Modified the test to listen() on "::1" INADDR6_LOOPBACK. A host without ipv6
disabled should report this as an error as it will not have an IPV6 loopback
available.


> proton.c ipv6 test does not detect lack of ipv6 support
> ---
>
> Key: PROTON-1639
> URL: https://issues.apache.org/jira/browse/PROTON-1639
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> This test tries to listen on the ipv6 "::" undefined address, and expects 
> that to fail if ipv6 is not supported, in which case it skips the remaining 
> ipv6 tests. However this has been broken at some point as the listen attempt 
> claims to succeed even if ipv6 has been disabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #212: DISPATCH-858 - Moved third party text into ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/212


---

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

[jira] [Commented] (PROTON-1639) proton.c ipv6 test does not detect lack of ipv6 support

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1639: epoll.c assert() on immediate connect() failure

The epoll proactor was asserting if a connect() call failed immediately.

This doesn't show up in most tests because the connect() is non-blocking, and
most failures are deferred to epoll and handled correctly

However trying to connect() to an IPv6 address with IPv6 disabled does fail
immediately and causes an assert() failure.


> proton.c ipv6 test does not detect lack of ipv6 support
> ---
>
> Key: PROTON-1639
> URL: https://issues.apache.org/jira/browse/PROTON-1639
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> This test tries to listen on the ipv6 "::" undefined address, and expects 
> that to fail if ipv6 is not supported, in which case it skips the remaining 
> ipv6 tests. However this has been broken at some point as the listen attempt 
> claims to succeed even if ipv6 has been disabled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1638) Need to improve proton-c build tree layout

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher commented on PROTON-1638:
-

That's interesting - I use kdevelop on a daily basis and hadn't noticed any 
deficiency with the IDE. I'm certainly open to adding the header files though.

> Need to improve proton-c build tree layout
> --
>
> Key: PROTON-1638
> URL: https://issues.apache.org/jira/browse/PROTON-1638
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>
> The proton-c tree layout is annoying in a number of ways:
> * Since the split with proton-j there is a superfluous top level
> * CMake build flags don't propagate properly because examples are not in the 
> correct subtree
> ** Examples should be in the binding subtree that they are examples
> ** Otherwise the information for a particular binding and its examples are 
> split into 2 different parts of the proton-c tree.
> ** This means that the installation for a binding is split
> ** It is unatural in CMake to split build flags like this - CMake is 
> hierarchical



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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