[jira] [Commented] (PROTON-1160) [Python binding] decimal32 and decimal64 are sent byte reversed
[
https://issues.apache.org/jira/browse/PROTON-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396422#comment-16396422
]
Justin Ross commented on PROTON-1160:
-
[~kpvdr], as a user of these APIs, how did you interface to the decimal types?
Are you passing in byte arrays, or was there something higher level?
> [Python binding] decimal32 and decimal64 are sent byte reversed
> ---
>
> Key: PROTON-1160
> URL: https://issues.apache.org/jira/browse/PROTON-1160
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> When sending {{decimal32}} and {{decimal64}} types to or from the Python
> binding, the byte order of the numbers are reversed. This does not apply to
> the {{decimal128}} type.
> It is noteworthy that this bug was exposed by qpid-interop-test when run
> against the C++ binding. In C++, these types are all based on a byte array,
> whereas in the Python binding, {{decimal32}} and {{decimal64}} are derived
> from Python types {{int}} and {{long}} respectively, while {{decimal128}} is
> derived from Python type {{bytes}}.
> Decimal32:
> {noformat}
> sent:['0x', '0x40490fdb', '0xc02df854', '0xff7f']
> received:['0x', '0xdb0f4940', '0x54f82dc0', '0x7fff']
> {noformat}
> Decimal64:
> {noformat}
> sent:['0x', '0x400921fb54442eea', '0xc005bf0a8b145fcf',
> '0xffef']
> received:['0x', '0xea2e4454fb210940', '0xcf5f148b0abf05c0',
> '0xefff']
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1160) [Python binding] decimal32 and decimal64 are sent byte reversed
[
https://issues.apache.org/jira/browse/PROTON-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396406#comment-16396406
]
Andrew Stitcher commented on PROTON-1160:
-
I'm not sure that "sent byte reversed" really has any meaning in the context of
the proton implementation of the decimalxx types: These types are actually
floating point types. But proton does not implement that floating point
semantic in any code whatever.
So it is perhaps moot to say that the python binding values are sent byte
reversed, since it is not defined what values we are actually sending!
For what it is worth I think the Ruby binding would agree with the Python byte
stream, so perhaps the C++ binding is in the minority here!
> [Python binding] decimal32 and decimal64 are sent byte reversed
> ---
>
> Key: PROTON-1160
> URL: https://issues.apache.org/jira/browse/PROTON-1160
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> When sending {{decimal32}} and {{decimal64}} types to or from the Python
> binding, the byte order of the numbers are reversed. This does not apply to
> the {{decimal128}} type.
> It is noteworthy that this bug was exposed by qpid-interop-test when run
> against the C++ binding. In C++, these types are all based on a byte array,
> whereas in the Python binding, {{decimal32}} and {{decimal64}} are derived
> from Python types {{int}} and {{long}} respectively, while {{decimal128}} is
> derived from Python type {{bytes}}.
> Decimal32:
> {noformat}
> sent:['0x', '0x40490fdb', '0xc02df854', '0xff7f']
> received:['0x', '0xdb0f4940', '0x54f82dc0', '0x7fff']
> {noformat}
> Decimal64:
> {noformat}
> sent:['0x', '0x400921fb54442eea', '0xc005bf0a8b145fcf',
> '0xffef']
> received:['0x', '0xea2e4454fb210940', '0xcf5f148b0abf05c0',
> '0xefff']
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4024) persistent message without content lead to server failed to start
[
https://issues.apache.org/jira/browse/QPID-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed QPID-4024.
-
Resolution: Won't Fix
> persistent message without content lead to server failed to start
> -
>
> Key: QPID-4024
> URL: https://issues.apache.org/jira/browse/QPID-4024
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: 0.16
> Environment: win7
>Reporter: yinshuwei
>Priority: Major
> Labels: patch
> Original Estimate: 0.05h
> Remaining Estimate: 0.05h
>
>I started server with this command:
> qpidd.exe --no-data-dir --auth=yes --load-module store/stored.dll
> --load-module store/mssql_stored.dll
>I found that if I send a message without content to the server and no
> consumer consume the message,when I go to restart the server,it will fail.
>There is a bug in src\qpid\store\ms-sql\MessageMapRecordset.cpp ,line :
> 115 ,method:recover
>
> // Now, do we need the rest of the content?
> long contentLength = blobSize - headerFieldLength - headerSize;
> if (msg->loadContent(contentLength)) {
> BlobAdapter content(contentLength);
> content =
> rs->Fields->Item["fieldTableBlob"]->GetChunk(contentLength);
> msg->decodeContent(content);
> }
> The problem here is that the variable contentLength's value is zero
> now,then execute the code :
>content =
> rs->Fields->Item["fieldTableBlob"]->GetChunk(contentLength);
> will lead to throw exception。
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4025) connections leak
[
https://issues.apache.org/jira/browse/QPID-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed QPID-4025.
-
Resolution: Cannot Reproduce
> connections leak
>
>
> Key: QPID-4025
> URL: https://issues.apache.org/jira/browse/QPID-4025
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.16
> Environment: win7
>Reporter: yinshuwei
>Priority: Major
> Labels: patch
>
>I used this command:
> spout -c 110 -b IP:port --content anything "q; {create:always,
> node:{type:queue, durable:true,
> x-declare:{arguments:{qpid.max_count:100,qpid.max_size:1024,qpid.policy_type:reject"
>
>But I got the exception:"session-busy: Session detached by peer" and the
> log :"2012-05-29 15:55:54 warning Exception received from broker:
> resource-limit-excee
> ded: resource-limit-exceeded: resource-limit-exceeded: Policy exceeded on q,
> pol
> icy: size: max=1024, current=700; count: max=100, current=100; type=reject
> (D:\c
> lib\qpidc-0.16\src\qpid\broker\QueuePolicy.cpp:87) [caused by 103 "
> I think when resource limit exceeded the connection should not be
> closed.Because more seriously,if I reconnect to the server in this case over
> and over,the server's connection limit will exceed.It seems that the client's
> connection is closed,but the server side still keep the connections.But when
> the client exit,the server side connections will be released.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4370) The change in qpid-config and qpid-stat options
[ https://issues.apache.org/jira/browse/QPID-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-4370. - Resolution: Won't Do > The change in qpid-config and qpid-stat options > --- > > Key: QPID-4370 > URL: https://issues.apache.org/jira/browse/QPID-4370 > Project: Qpid > Issue Type: Bug > Components: C++ Tools >Affects Versions: Future >Reporter: Ernest Allen >Priority: Major > Labels: patch > Attachments: qpid-config_revert-args.patch > > > The following changes need to be made: > qpid-config: > - change the "-b --broker" general option to be -a --broker-addr > - change the "-r --recursive" general option to be -b --bindings > effectively reverting those cli options to the previous version > qpid-stat: > - remove the "-b --broker" general option and allow the broker to be passed > without an option letter > - change the "-g --general" general option to be -b --broker for show broker > stats > reverting those cli options to the previous version -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5824) Add reset method to qpid::messaging::Session
[ https://issues.apache.org/jira/browse/QPID-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396402#comment-16396402 ] Justin Ross commented on QPID-5824: --- I feel like I probably put the patch label on this, but I see no patch. [~gsim], did a patch ever exist for this? > Add reset method to qpid::messaging::Session > > > Key: QPID-5824 > URL: https://issues.apache.org/jira/browse/QPID-5824 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.26 >Reporter: Clive Lilley >Assignee: Gordon Sim >Priority: Minor > Labels: patch > Fix For: Future > > > The qpid::messaging API can reconnect to a broker (automatically or manually) > and reset any already created sessions using the reconnect functionality. But > an edge case exists where the qpid::messaging::Connection has a valid and > open connection to the broker, but one or more associated sessions have an > error, due to receiving an exception. The only way to fix this situation is > to close the Session that is in error and create a new one. This is not > always desirable, as the corresponding set of Senders and Receivers would > also need closing and recreating. What is really needed is a reset method on > the qpid::messaging::Session Class. This would use some of the functionality > already provided in the reconnect implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1640) ruby-data-spec test fails on Raspbian Stretch
[
https://issues.apache.org/jira/browse/PROTON-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-1640:
Environment:
Raspberry Pi 3
Raspbian Stretch
32 bits
was:
Raspberry Pi 3
Raspbian Stretch
> ruby-data-spec test fails on Raspbian Stretch
> -
>
> Key: PROTON-1640
> URL: https://issues.apache.org/jira/browse/PROTON-1640
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: Raspberry Pi 3
> Raspbian Stretch
> 32 bits
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> Building/Testing 0.18 RC1:
> The only problem is this failure in the ruby tests:
> {noformat}
> Start 19: ruby-data-spec
>
> 19: Test command: /usr/bin/ruby
> "/home/andrew/Source/qpid-proton/qpid-proton-0.18.0
> proton-c/bindings/ruby/spec/data_spec.rb" "-v"
>
> 19: Environment variables:
> 19:
> PATH=/home/andrew/.cargo/bin:/home/andrew/.local/bin:/home/andrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
>
> 19:
> RUBYLIB=:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/lib:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/tests:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/spec:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
> 19: Test timeout computed to be: 1500
> 19: Run options: -v --seed 49451
> 19:
> 19: # Running:
> 19:
> 19: A data object#test_0028_raises an error on a negative ulong = 0.00 s = .
> 19: A data object#test_0031_raises an error on a null long = 0.00 s = .
> 19: A data object#test_0053_can hold a zero decimal128 = 0.00 s = .
> 19: A data object#test_0003_can hold a true boolean = 0.00 s = .
> 19: A data object#test_0056_raises an error on a malformed UUID = 0.00 s = .
> 19: A data object#test_0010_raises an error on a negative ushort = 0.00 s = .
> 19: A data object#test_0047_can hold a zero decimal32 = 0.00 s = .
> 19: A data object#test_0052_raises an error on a null decimal128 = 0.00 s = .
> 19: A data object#test_0065_can hold a described value = 0.00 s = .
> 19: A data object#test_0012_can hold a zero unsigned short = 0.00 s = .
> 19: A data object#test_0021_can hold a zero unsigned integer = 0.00 s = .
> 19: A data object#test_0035_can handle a negative timestamp = 0.00 s = .
> 19: A data object#test_0040_can hold a zero float = 0.00 s = .
> 19: A data object#test_0042_raise an error on a null double = 0.00 s = .
> 19: A data object#test_0069_can hold a list = 0.04 s = .
> 19: A data object#test_0037_can hold a timestamp = 0.00 s = .
> 19: A data object#test_0050_can hold a zero decimal64 = 0.00 s = .
> 19: A data object#test_0070_can hold a map = 0.09 s = .
> 19: A data object#test_0032_can have a zero long = 0.00 s = .
> 19: A data object#test_0007_can hold an unsigned byte = 0.00 s = .
> 19: A data object#test_0018_raises an error on a nil uint = 0.00 s = .
> 19: A data object#test_0067_can hold an array = 0.00 s = .
> 19: A data object#test_0054_can hold a decimal128 = 0.00 s = .
> 19: A data object#test_0026_can hold a character = 0.00 s = .
> 19: A data object#test_0017_can hold a negative short = 0.00 s = .
> 19: A data object#test_0036_can handle a zero timestamp = 0.00 s = .
> 19: A data object#test_0059_can hold a null binary = 0.00 s = .
> 19: A data object#test_0068_can hold a described array = 0.03 s = .
> 19: A data object#test_0015_can hold a short = 0.00 s = .
> 19: A data object#test_0048_can hold a decimal32 = 0.00 s = F
> 19: A data object#test_0011_raises an error on a nil ushort = 0.00 s = .
> 19: A data object#test_0063_can hold a null symbol = 0.00 s = .
> 19: A data object#test_0020_can hold an unsigned integer = 0.00 s = .
> 19: A data object#test_0004_can hold a false boolean = 0.00 s = .
> 19: A data object#test_0014_raises an error on a nil short = 0.00 s = .
> 19: A data object#test_0058_can hold a UUID = 0.00 s = .
> 19: A data object#test_0045_can hold a double = 0.00 s = .
[jira] [Resolved] (PROTON-1640) ruby-data-spec test fails on Raspbian Stretch
[
https://issues.apache.org/jira/browse/PROTON-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1640.
-
Resolution: Fixed
Assignee: Andrew Stitcher (was: Alan Conway)
Fix Version/s: proton-c-0.22.0
This turned out to be an issue with 32 bit ruby rather than the raspberry pi
per se.
The handling of the decimal32 type (this is a floating point type using 32 bits
like float32 but with a decimal exponent) was assuming the FIXNUM type which on
32 bit systems is 31 bits and doesn't have enough space to represent all
values. It also wasn't checking the types before conversion.
> ruby-data-spec test fails on Raspbian Stretch
> -
>
> Key: PROTON-1640
> URL: https://issues.apache.org/jira/browse/PROTON-1640
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: Raspberry Pi 3
> Raspbian Stretch
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> Building/Testing 0.18 RC1:
> The only problem is this failure in the ruby tests:
> {noformat}
> Start 19: ruby-data-spec
>
> 19: Test command: /usr/bin/ruby
> "/home/andrew/Source/qpid-proton/qpid-proton-0.18.0
> proton-c/bindings/ruby/spec/data_spec.rb" "-v"
>
> 19: Environment variables:
> 19:
> PATH=/home/andrew/.cargo/bin:/home/andrew/.local/bin:/home/andrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
>
> 19:
> RUBYLIB=:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/lib:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/tests:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/spec:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
> 19: Test timeout computed to be: 1500
> 19: Run options: -v --seed 49451
> 19:
> 19: # Running:
> 19:
> 19: A data object#test_0028_raises an error on a negative ulong = 0.00 s = .
> 19: A data object#test_0031_raises an error on a null long = 0.00 s = .
> 19: A data object#test_0053_can hold a zero decimal128 = 0.00 s = .
> 19: A data object#test_0003_can hold a true boolean = 0.00 s = .
> 19: A data object#test_0056_raises an error on a malformed UUID = 0.00 s = .
> 19: A data object#test_0010_raises an error on a negative ushort = 0.00 s = .
> 19: A data object#test_0047_can hold a zero decimal32 = 0.00 s = .
> 19: A data object#test_0052_raises an error on a null decimal128 = 0.00 s = .
> 19: A data object#test_0065_can hold a described value = 0.00 s = .
> 19: A data object#test_0012_can hold a zero unsigned short = 0.00 s = .
> 19: A data object#test_0021_can hold a zero unsigned integer = 0.00 s = .
> 19: A data object#test_0035_can handle a negative timestamp = 0.00 s = .
> 19: A data object#test_0040_can hold a zero float = 0.00 s = .
> 19: A data object#test_0042_raise an error on a null double = 0.00 s = .
> 19: A data object#test_0069_can hold a list = 0.04 s = .
> 19: A data object#test_0037_can hold a timestamp = 0.00 s = .
> 19: A data object#test_0050_can hold a zero decimal64 = 0.00 s = .
> 19: A data object#test_0070_can hold a map = 0.09 s = .
> 19: A data object#test_0032_can have a zero long = 0.00 s = .
> 19: A data object#test_0007_can hold an unsigned byte = 0.00 s = .
> 19: A data object#test_0018_raises an error on a nil uint = 0.00 s = .
> 19: A data object#test_0067_can hold an array = 0.00 s = .
> 19: A data object#test_0054_can hold a decimal128 = 0.00 s = .
> 19: A data object#test_0026_can hold a character = 0.00 s = .
> 19: A data object#test_0017_can hold a negative short = 0.00 s = .
> 19: A data object#test_0036_can handle a zero timestamp = 0.00 s = .
> 19: A data object#test_0059_can hold a null binary = 0.00 s = .
> 19: A data object#test_0068_can hold a described array = 0.03 s = .
> 19: A data object#test_0015_can hold a short = 0.00 s = .
> 19: A data object#test_0048_can hold a decimal32 = 0.00 s = F
> 19: A data object#test_0011_raises an error on a nil ushort = 0.00 s = .
> 19: A
[jira] [Commented] (PROTON-1640) ruby-data-spec test fails on Raspbian Stretch
[
https://issues.apache.org/jira/browse/PROTON-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396396#comment-16396396
]
ASF subversion and git services commented on PROTON-1640:
-
Commit 7f677ae4abb8cf2fcff92a9a61a71b645d673189 in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7f677ae ]
PROTON-1640: [ruby] Fix handling of decimal32 type on 32 bit systems
> ruby-data-spec test fails on Raspbian Stretch
> -
>
> Key: PROTON-1640
> URL: https://issues.apache.org/jira/browse/PROTON-1640
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: Raspberry Pi 3
> Raspbian Stretch
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>Priority: Major
>
> Building/Testing 0.18 RC1:
> The only problem is this failure in the ruby tests:
> {noformat}
> Start 19: ruby-data-spec
>
> 19: Test command: /usr/bin/ruby
> "/home/andrew/Source/qpid-proton/qpid-proton-0.18.0
> proton-c/bindings/ruby/spec/data_spec.rb" "-v"
>
> 19: Environment variables:
> 19:
> PATH=/home/andrew/.cargo/bin:/home/andrew/.local/bin:/home/andrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
>
> 19:
> RUBYLIB=:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/lib:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/tests:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/spec:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
> 19: Test timeout computed to be: 1500
> 19: Run options: -v --seed 49451
> 19:
> 19: # Running:
> 19:
> 19: A data object#test_0028_raises an error on a negative ulong = 0.00 s = .
> 19: A data object#test_0031_raises an error on a null long = 0.00 s = .
> 19: A data object#test_0053_can hold a zero decimal128 = 0.00 s = .
> 19: A data object#test_0003_can hold a true boolean = 0.00 s = .
> 19: A data object#test_0056_raises an error on a malformed UUID = 0.00 s = .
> 19: A data object#test_0010_raises an error on a negative ushort = 0.00 s = .
> 19: A data object#test_0047_can hold a zero decimal32 = 0.00 s = .
> 19: A data object#test_0052_raises an error on a null decimal128 = 0.00 s = .
> 19: A data object#test_0065_can hold a described value = 0.00 s = .
> 19: A data object#test_0012_can hold a zero unsigned short = 0.00 s = .
> 19: A data object#test_0021_can hold a zero unsigned integer = 0.00 s = .
> 19: A data object#test_0035_can handle a negative timestamp = 0.00 s = .
> 19: A data object#test_0040_can hold a zero float = 0.00 s = .
> 19: A data object#test_0042_raise an error on a null double = 0.00 s = .
> 19: A data object#test_0069_can hold a list = 0.04 s = .
> 19: A data object#test_0037_can hold a timestamp = 0.00 s = .
> 19: A data object#test_0050_can hold a zero decimal64 = 0.00 s = .
> 19: A data object#test_0070_can hold a map = 0.09 s = .
> 19: A data object#test_0032_can have a zero long = 0.00 s = .
> 19: A data object#test_0007_can hold an unsigned byte = 0.00 s = .
> 19: A data object#test_0018_raises an error on a nil uint = 0.00 s = .
> 19: A data object#test_0067_can hold an array = 0.00 s = .
> 19: A data object#test_0054_can hold a decimal128 = 0.00 s = .
> 19: A data object#test_0026_can hold a character = 0.00 s = .
> 19: A data object#test_0017_can hold a negative short = 0.00 s = .
> 19: A data object#test_0036_can handle a zero timestamp = 0.00 s = .
> 19: A data object#test_0059_can hold a null binary = 0.00 s = .
> 19: A data object#test_0068_can hold a described array = 0.03 s = .
> 19: A data object#test_0015_can hold a short = 0.00 s = .
> 19: A data object#test_0048_can hold a decimal32 = 0.00 s = F
> 19: A data object#test_0011_raises an error on a nil ushort = 0.00 s = .
> 19: A data object#test_0063_can hold a null symbol = 0.00 s = .
> 19: A data object#test_0020_can hold an unsigned integer = 0.00 s = .
> 19: A data object#test_0004_can hold a false boolean = 0.00 s = .
> 19: A
[GitHub] qpid-cpp issue #12: WIP - A batch of C++ updates
Github user ssorj commented on the issue: https://github.com/apache/qpid-cpp/pull/12 The related issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20and%20resolution%20is%20null%20and%20component%20in%20(%22C%2B%2B%20Broker%22%2C%20%22C%2B%2B%20Build%22%2C%20%22C%2B%2B%20Client%22%2C%20%22C%2B%2B%20Clustering%22%2C%20%22C%2B%2B%20Documentation%22%2C%20%22C%2B%2B%20Tests%22%2C%20%22C%2B%2B%20Tools%22%2C%20%22.NET%20Client%22%2C%20%22Perl%20Client%22%2C%20%22Python%20Client%20(Wrapped)%22%2C%20%22QMF%22%2C%20%22Ruby%20Client%22)%20and%20fixversion%20%3D%20qpid-cpp-1.38.0%20 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-cpp pull request #12: WIP - A batch of C++ updates
GitHub user ssorj opened a pull request: https://github.com/apache/qpid-cpp/pull/12 WIP - A batch of C++ updates This is a slate of doc updates and patch applications for the C++ code base. Please let me know if you see any problems here. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ssorj/qpid-cpp master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-cpp/pull/12.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #12 commit 5899b313ae9a9cbf0d70bfa55527ebdd5c6addc7 Author: Justin Ross Date: 2018-01-09T23:34:43Z QPID-8073: Add missing package to help text commit 4b1463abab12ae3d6b18c47ade723213fc6d2d6c Author: Justin Ross Date: 2018-03-12T18:32:28Z QPID-8128: Link to libqpid-proton-core, not libqpid-proton; remove an obsolete way to find the proton config commit ce769f7790e726ba84932ba57a209cb9d322abaa Author: Justin Ross Date: 2018-03-12T19:41:15Z QPID-8072, QPID-8129: Remove the long deprecated Ruby and Python bindings to QMF2 commit 8d036fa5accf496eba39a838cffc553d30ddda93 Author: Justin Ross Date: 2018-03-12T20:15:04Z QPID-7051: Fix crash after reconnect with transactional session. This is a patch from HÃ¥kan Johansson commit e17a6f85a1bf90c51520d7ad7ed6739e81a84fdf Author: Justin Ross Date: 2018-03-12T20:49:23Z QPID-7999: Move Fedora-specific init scripts to the fedora dir; disable their installation, but keep them in the build output so packagers can pick them up as needed commit 25590819c54a780f2a48c74ad19bbe4c30bf0bc9 Author: Justin Ross Date: 2018-03-12T22:05:50Z QPID-7089: Add a note linking to OS packages commit 00a7e9bb7975808659076fadfcbfd1bb64c5ed24 Author: Justin Ross Date: 2018-03-12T22:37:45Z QPID-7821: Add man pages for all executables. Adapted from a patch from Irina Boverman. commit 6186f50d0fdb73ef76918d163473c6e2a905f39c Author: Justin Ross Date: 2018-03-12T23:37:14Z QPID-7630: Add a CMake switch to allow -Werror to be switched off commit 9da6baaf7f67ad446c386070643449c8a23d6188 Author: Justin Ross Date: 2018-03-12T23:52:42Z QPID-8128: Remove the Proton version warning and raise the minimum version commit 889813351649b9cdeef26b211d34eb87c9c5f1f6 Author: Justin Ross Date: 2018-03-13T01:08:20Z QPID-7054: Fix crash when closing a sender after the connection has been closed. Thanks to HÃ¥kan Johansson for the patch. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6774) Can't compile unit_test with boost 1.59.0
[
https://issues.apache.org/jira/browse/QPID-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated QPID-6774:
--
Fix Version/s: (was: qpid-cpp-1.38.0)
> Can't compile unit_test with boost 1.59.0
> -
>
> Key: QPID-6774
> URL: https://issues.apache.org/jira/browse/QPID-6774
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
>Assignee: Justin Ross
>Priority: Major
>
> QPID-6771:
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE":
> 找不到标识符
> BOOST_MESSAGE was removed from boost 1.59.0, we should add it.
>
> from:
> namespace tests {
> QPID_AUTO_TEST_SUITE(exception_test)
> to:
> namespace tests {
> #ifndef BOOST_MESSAGE
> #define BOOST_MESSAGE( M ) BOOST_TEST_MESSAGE( M )
> #endif
> QPID_AUTO_TEST_SUITE(exception_test)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-6774) Can't compile unit_test with boost 1.59.0
[
https://issues.apache.org/jira/browse/QPID-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed QPID-6774.
-
Resolution: Cannot Reproduce
Assignee: Justin Ross
I found no instance of BOOST_MESSAGE in the source tree. There was one
instance of BOOST_TEST_MESSAGE (in exception_test.cpp), so it looks like this
has been addressed another way.
> Can't compile unit_test with boost 1.59.0
> -
>
> Key: QPID-6774
> URL: https://issues.apache.org/jira/browse/QPID-6774
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: Windows xp sp3, VC2008 no sp,boost 1.59.0
>Reporter: sxf
>Assignee: Justin Ross
>Priority: Major
> Fix For: qpid-cpp-1.38.0
>
>
> QPID-6771:
> 3)..\..\..\src\tests\exception_test.cpp(66) : error C3861: "BOOST_MESSAGE":
> 找不到标识符
> BOOST_MESSAGE was removed from boost 1.59.0, we should add it.
>
> from:
> namespace tests {
> QPID_AUTO_TEST_SUITE(exception_test)
> to:
> namespace tests {
> #ifndef BOOST_MESSAGE
> #define BOOST_MESSAGE( M ) BOOST_TEST_MESSAGE( M )
> #endif
> QPID_AUTO_TEST_SUITE(exception_test)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7821) Missing man pages
[ https://issues.apache.org/jira/browse/QPID-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-7821: - Assignee: Justin Ross > Missing man pages > - > > Key: QPID-7821 > URL: https://issues.apache.org/jira/browse/QPID-7821 > Project: Qpid > Issue Type: Bug > Components: C++ Documentation >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 >Reporter: Irina Boverman >Assignee: Justin Ross >Priority: Minor > Fix For: qpid-cpp-1.38.0 > > Attachments: 0001-Added-man-pages.patch > > > Debian distribution requires all binaries to have man pages. These do not: > ../build.log:W: qpid-receive: binary-without-manpage usr/bin/qpid-receive > ../build.log:W: qpid-send: binary-without-manpage usr/bin/qpid-send > ../build.log:W: qmf-gen: binary-without-manpage usr/bin/qmf-gen > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-config > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-ha > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-printevents > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-queue-stats > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-route > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-stat > ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-tool -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8056) qpid::messaging::ConnectionContext crash after network disconnect (with patch)
[
https://issues.apache.org/jira/browse/QPID-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned QPID-8056:
-
Assignee: Justin Ross
> qpid::messaging::ConnectionContext crash after network disconnect (with patch)
> --
>
> Key: QPID-8056
> URL: https://issues.apache.org/jira/browse/QPID-8056
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: RedHat Enterprise Linux 6
>Reporter: Håkan Johansson
>Assignee: Justin Ross
>Priority: Major
> Labels: crash
> Fix For: qpid-cpp-1.38.0
>
> Attachments: connection_context.diff, valgrind.txt
>
>
> When doing HA testing we found that our application often crashed inside the
> Qpid Messaging library.
> Our test:
> * One ActiveMQ broker.
> * Two proxies connecting to the AMQP port on the broker. At the start, only
> one of the proxies are running.
> * Test program configured to use failover between the two proxies. Protocol
> is "amqp1.0". It reads messages in a loop using a transactional session. On
> error it closes the connection and opens a new.
> * Three queues are read from in parallel, each reader using its own
> connection in a thread. Nothing is shared between the threads in the client
> code.
> * Send some messages and let the test program process them.
> * Stop proxy1 and start proxy2.
> * Send some more messages and let the test program process them.
> * Stop proxy2 and start proxy1.
> * And so on...
> After a couple of switches the test program crashes, but not always. It's a
> timing thing.
> A typical error message that we see before the crash:
> {noformat}
> Exception when trying to close the qpid connection: Transaction outcome
> unknown: transport failure
> {noformat}
> The reason for the crash is that the poller thread is still active when the
> connection is being deleted. The destructor of the
> {{qpid::messaging::ConnectionContext}} class deletes the {{TcpTransport}}
> instance at the same time as, or right before, the poller thread is calling a
> callback on it ({{qpid::messaging::amqp::TcpTransport::disconnected}}).
> I have attached a patch to solve the issue, at least for this use case.
> I cannot test this on {{1.37.0}} as I cannot build that version on RHEL6 as
> it uses Python 2.6 which is no longer supported in {{1.37.0}}. The code in
> question is identical in {{1.36.0}} and {{1.37.0}} though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7054) Crash when closing a sender after the connection has been closed (with patch).
[ https://issues.apache.org/jira/browse/QPID-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-7054: - Assignee: Justin Ross > Crash when closing a sender after the connection has been closed (with patch). > -- > > Key: QPID-7054 > URL: https://issues.apache.org/jira/browse/QPID-7054 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-0.34 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > The broker is ActiveMQ 5.13.0. > The protocol used in AMQP 1.0. >Reporter: Håkan Johansson >Assignee: Justin Ross >Priority: Major > Labels: crash, patch > Fix For: qpid-cpp-1.38.0 > > Attachments: crash_test.cc, qpid-7054.2.patch, qpid-7054.patch > > > There will be a crash if you close your _Sender_ after the _Connection_ has > been closed. > To reproduce, compile and run the attached "crash_test.cc" file. > The test program is very simple. It creates _Connection_, _Session_, and > _Sender_ instances, then closes the connection explicitly followed by closing > the sender. The closing of the sender causes an exception to be thrown as the > connection is dead, but that is caught. > The crash happens when the _Session_ object is destructed at the end of the > test function. This causes the _SenderContext_ from the sender to be > destructed, which tries to close the underlying _pn_link_t_ object to be > freed, but that object refers to a deleted _pn_connection_t_ object. The > exception during _Sender::close_ stopped the proper cleanup to be done. > The _Sender::close_ method calls _ConnectionContext::detach_ to disconnect it > from its session. One problem here is that the _Connection::close_ method > made the connection forget all its sessions, but the sessions still remember > their connection, including the underlying proton objects. The connection > tries to reconnect to the broker and resets its internal connection, causing > the proton connection object to be freed. It then tells all its sessions > about this, but those are forgotten earlier. This means that we end up with > _pn_link_t_ objects that refer to a deleted _pn_connection_t_ object. > I have a attached a patch to this jira which stops the > _ConnectionContext::detach_ method from trying to do remote actions if not > connected. The row numbers in this patch assumes that the patch in QPID-7051 > is already applied, which might cause some offset warnings when applying this > patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7054) Crash when closing a sender after the connection has been closed (with patch).
[ https://issues.apache.org/jira/browse/QPID-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7054: -- Fix Version/s: qpid-cpp-1.38.0 > Crash when closing a sender after the connection has been closed (with patch). > -- > > Key: QPID-7054 > URL: https://issues.apache.org/jira/browse/QPID-7054 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-0.34 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > The broker is ActiveMQ 5.13.0. > The protocol used in AMQP 1.0. >Reporter: Håkan Johansson >Priority: Major > Labels: crash, patch > Fix For: qpid-cpp-1.38.0 > > Attachments: crash_test.cc, qpid-7054.2.patch, qpid-7054.patch > > > There will be a crash if you close your _Sender_ after the _Connection_ has > been closed. > To reproduce, compile and run the attached "crash_test.cc" file. > The test program is very simple. It creates _Connection_, _Session_, and > _Sender_ instances, then closes the connection explicitly followed by closing > the sender. The closing of the sender causes an exception to be thrown as the > connection is dead, but that is caught. > The crash happens when the _Session_ object is destructed at the end of the > test function. This causes the _SenderContext_ from the sender to be > destructed, which tries to close the underlying _pn_link_t_ object to be > freed, but that object refers to a deleted _pn_connection_t_ object. The > exception during _Sender::close_ stopped the proper cleanup to be done. > The _Sender::close_ method calls _ConnectionContext::detach_ to disconnect it > from its session. One problem here is that the _Connection::close_ method > made the connection forget all its sessions, but the sessions still remember > their connection, including the underlying proton objects. The connection > tries to reconnect to the broker and resets its internal connection, causing > the proton connection object to be freed. It then tells all its sessions > about this, but those are forgotten earlier. This means that we end up with > _pn_link_t_ objects that refer to a deleted _pn_connection_t_ object. > I have a attached a patch to this jira which stops the > _ConnectionContext::detach_ method from trying to do remote actions if not > connected. The row numbers in this patch assumes that the patch in QPID-7051 > is already applied, which might cause some offset warnings when applying this > patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8048) Qpid C++ 1.38.0 release tasks
[ https://issues.apache.org/jira/browse/QPID-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-8048: - Assignee: Justin Ross (was: Robbie Gemmell) > Qpid C++ 1.38.0 release tasks > - > > Key: QPID-8048 > URL: https://issues.apache.org/jira/browse/QPID-8048 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8129) Remove the obsolete Python management API
Justin Ross created QPID-8129: - Summary: Remove the obsolete Python management API Key: QPID-8129 URL: https://issues.apache.org/jira/browse/QPID-8129 Project: Qpid Issue Type: Task Components: C++ Broker Reporter: Justin Ross Assignee: Justin Ross Fix For: qpid-cpp-1.38.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7089) Documentation should point to PPA for Debian/Ubuntu
[ https://issues.apache.org/jira/browse/QPID-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7089: -- Fix Version/s: qpid-cpp-1.38.0 > Documentation should point to PPA for Debian/Ubuntu > --- > > Key: QPID-7089 > URL: https://issues.apache.org/jira/browse/QPID-7089 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 > Environment: Debian/Ubuntu >Reporter: Morgan Lindqvist >Assignee: Justin Ross >Priority: Minor > Labels: easyfix > Fix For: qpid-cpp-1.38.0 > > > On the QPID C++ broker page > (https://qpid.apache.org/components/cpp-broker/index.html) there is a link in > the bottom of the page to "Installing Qpid C++" > (http://svn.apache.org/repos/asf/qpid/tags/qpid-cpp-0.34/qpid/cpp/INSTALL) > This installation instruction do not contain the information that there exist > a PPA for QPID C++ (or rather all of the QPID projects) and that precompiled > binaries can be installed. > The information that should be added is that the page > https://launchpad.net/~qpid contains instructions on how to install both > release and testing packages of QPID C++ broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4166) Add all possible qpidd configuration settings to /etc/qpidd.conf
[ https://issues.apache.org/jira/browse/QPID-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-4166. - Resolution: Won't Do I'm personally not a fan of config files that do this. As it happens, qpidd makes it easy to find the config file entries and defaults in the man page. > Add all possible qpidd configuration settings to /etc/qpidd.conf > - > > Key: QPID-4166 > URL: https://issues.apache.org/jira/browse/QPID-4166 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, Packaging >Reporter: Noel O'Connor >Assignee: Justin Ross >Priority: Minor > > Add all qpidd configuration options to the qpidd.conf file installed into the > /etc/ directory. The default setting should be that the majority of settings > are commented out. This is useful for further configuration rather than > copy/pasting from docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8128) [cpp] Link to libqpid-proton-core, not libqpid-proton
Justin Ross created QPID-8128: - Summary: [cpp] Link to libqpid-proton-core, not libqpid-proton Key: QPID-8128 URL: https://issues.apache.org/jira/browse/QPID-8128 Project: Qpid Issue Type: Task Components: C++ Broker, C++ Client Reporter: Justin Ross Assignee: Justin Ross Fix For: qpid-cpp-1.38.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395582#comment-16395582 ] ASF subversion and git services commented on QPID-8123: --- Commit 073f27ee7bf88847efa1062273b1b7d63b8c0bcf in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=073f27e ] QPID-8123: [Broker-J] [System Tests] Remove remaining compile time references from test code to the Qpid JMS AMQP 0-x client (mainly Strings and FileUtils) > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395488#comment-16395488 ] ASF subversion and git services commented on QPID-8123: --- Commit c09a9a316fdadcf3b8af21661fbc5ccb3e1baa0a in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c09a9a3 ] QPID-8123: [Broker-J] [BDB System Tests] Refactor MultiNodeTest and TwoNodeTest to remove knowledge of Qpid JMS AMQP 0-x client (code dependency and format of failover url). > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395489#comment-16395489 ] ASF subversion and git services commented on QPID-8123: --- Commit 6b31d0fd7bb2f31f65e68227610a6a50c2d758fe in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6b31d0f ] QPID-8123: [Broker-J] [BDB System Tests] Remove Qpid JMS AMQP 0-x client dependencies from BDBUpgradeTest > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: qpid_proton Ruby Binding Leaking File Descriptors
Please raise a JIRA at issues.apache.org? I will fix it ASAP - I'd like to get that fixed before the next release. If you can find a simple way to demonstrate the problem (e.g. using the example programs and and lsof) that would help. On Mon, Mar 12, 2018 at 8:06 AM, Miha Pleško wrote: > > Hi guys, > > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > > Too many open files - socket(2) for " 172.16.117.189 " port 5672 > > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > > $ lsof -ap 108533 > ruby 108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp > (CLOSE_WAIT) > ruby 108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp > (CLOSE_WAIT) > ... > > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > > We did all we could to close connections gracefully: > > connection.container.stop > connection.close > connection = nil > > but nothing seems to help. A simple but expensive workaround is to > manually invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > > May I kindly ask you to look at this? > > > > Thank you and Best Regards, > Miha > > PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 > PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0 > >
[jira] [Created] (QPID-8127) [Broker-J][ACL] Allow case insensitive matching of group and user names in existing ACL
Alex Rudyy created QPID-8127: Summary: [Broker-J][ACL] Allow case insensitive matching of group and user names in existing ACL Key: QPID-8127 URL: https://issues.apache.org/jira/browse/QPID-8127 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Alex Rudyy The current ACL rules matching functionality is case sensitive for user names and group names. When SimpleLdap authentication provider is configured and groups are fetched from LDAP as distinguished names, it is quite easy to make a mistake in group/user DN and put some of letter in wrong case as LDAP DN search is case-insensitive. Thus, users can specify some parts of DN in ACL using letters in wrong case. The debugging of such mistyped names can be time-consuming. IMHO, it make more sense to add ability into ACL implementation to match groups and user names in case insensitive way. The following link provides a good overview of case sensitivity of DN: [http://ldapwiki.com/wiki/Distinguished%20Name%20Case%20Sensitivity] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8126) [Broker-J][SimpleLDAP] NPE is reported into broker logs when serach user is specified but search password is not set
Alex Rudyy created QPID-8126:
Summary: [Broker-J][SimpleLDAP] NPE is reported into broker logs
when serach user is specified but search password is not set
Key: QPID-8126
URL: https://issues.apache.org/jira/browse/QPID-8126
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0,
qpid-java-broker-7.0.2
Reporter: Alex Rudyy
Creation of authentication provider with search username and missing search
password ends up in NPE reported into broker logs like the one below:
{noformat}
java.lang.NullPointerException: null
at java.util.Hashtable.put(Hashtable.java:460)
at
org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.setupSearchContext(SimpleLDAPAuthenticationManagerImpl.java:602)
at
org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.validateInitialDirContext(SimpleLDAPAuthenticationManagerImpl.java:577)
at
org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.validateOnCreate(SimpleLDAPAuthenticationManagerImpl.java:159)
at
org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:879)
at
org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:866)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:629)
at
org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:865)
at
org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:75)
at
org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:145)
at
org.apache.qpid.server.model.AbstractConfiguredObject.addChildAsync(AbstractConfiguredObject.java:2111)
at
org.apache.qpid.server.model.BrokerImpl.addChildAsync(BrokerImpl.java:697)
at
org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2068)
at
org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2063)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
at
com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
at
com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)
at
com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Though, it is unlikely that any LDAP server would be configured to allow
specification of search username without a password, the creation of provider
should not end-up in NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1790) [ruby] Link name is not generated in open_sender when using hash as parameter
[
https://issues.apache.org/jira/browse/PROTON-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1790:
Affects Version/s: proton-c-0.21.0
> [ruby] Link name is not generated in open_sender when using hash as parameter
> -
>
> Key: PROTON-1790
> URL: https://issues.apache.org/jira/browse/PROTON-1790
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.21.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See https://issues.jboss.org/browse/ENTMQCL-645
> When using:
> container.connect(...).open_sender("")
> Link name is generated and used in attach phase (trace).
> [0x1a41270]:0 -> @attach(18) [name="f32b20d8-236e-4d21-9f0d-50afd0e5a6ad/1",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0, max-message-size=0]
> When using:
> container.connect(...).open_sender({:target => ""})
> Link name is NOT generated and is empty in attach phase (trace).
> [0x199f3c0]:0 -> @attach(18) [handle=0, role=false, snd-settle-mode=2,
> rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> Link name is mandatory. If link name is not set, broker immediately closes
> the connection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management
[
https://issues.apache.org/jira/browse/QPID-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395323#comment-16395323
]
Alex Rudyy commented on QPID-8124:
--
Perhaps, we can provide the details of all user principal when outcome is
Denied either in operational log itself or in additional debug level logs
> [Broker-J][REST] Sucessfully authenticated user is reported as <> in
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
>
> When user is successfully authenticated, the user information in operational
> log for checking management access is reported as <> for both
> Allowed and Denied outcomes:
> {noformat}
> INFO [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied :
> Access Management
> INFO [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed :
> Access Management
> INFO [qtp1675859208-64] (q.m.m.open) -
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated
> user in operational log when access is denied.
> Thought, it is possible to get the principal name for "allowed" outcome by
> looking into the following logs from the same thread, it would be beneficial
> to print the real principal information in the log for Allowed outcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1790) [ruby] Link name is not generated in open_sender when using hash as parameter
[
https://issues.apache.org/jira/browse/PROTON-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1790:
---
Assignee: Alan Conway
> [ruby] Link name is not generated in open_sender when using hash as parameter
> -
>
> Key: PROTON-1790
> URL: https://issues.apache.org/jira/browse/PROTON-1790
> Project: Qpid Proton
> Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See https://issues.jboss.org/browse/ENTMQCL-645
> When using:
> container.connect(...).open_sender("")
> Link name is generated and used in attach phase (trace).
> [0x1a41270]:0 -> @attach(18) [name="f32b20d8-236e-4d21-9f0d-50afd0e5a6ad/1",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0, max-message-size=0]
> When using:
> container.connect(...).open_sender({:target => ""})
> Link name is NOT generated and is empty in attach phase (trace).
> [0x199f3c0]:0 -> @attach(18) [handle=0, role=false, snd-settle-mode=2,
> rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> Link name is mandatory. If link name is not set, broker immediately closes
> the connection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1790) [ruby] Link name is not generated in open_sender when using hash as parameter
Alan Conway created PROTON-1790:
---
Summary: [ruby] Link name is not generated in open_sender when
using hash as parameter
Key: PROTON-1790
URL: https://issues.apache.org/jira/browse/PROTON-1790
Project: Qpid Proton
Issue Type: Bug
Reporter: Alan Conway
See https://issues.jboss.org/browse/ENTMQCL-645
When using:
container.connect(...).open_sender("")
Link name is generated and used in attach phase (trace).
[0x1a41270]:0 -> @attach(18) [name="f32b20d8-236e-4d21-9f0d-50afd0e5a6ad/1",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[durable=0, timeout=0, dynamic=false], target=@target(41) [address="",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
When using:
container.connect(...).open_sender({:target => ""})
Link name is NOT generated and is empty in attach phase (trace).
[0x199f3c0]:0 -> @attach(18) [handle=0, role=false, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [address="", durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
Link name is mandatory. If link name is not set, broker immediately closes the
connection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8125) [Broker-J][Documentation] Document node auto-creation policies in Broker docbook
Alex Rudyy created QPID-8125: Summary: [Broker-J][Documentation] Document node auto-creation policies in Broker docbook Key: QPID-8125 URL: https://issues.apache.org/jira/browse/QPID-8125 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0, qpid-java-broker-7.0.2 Reporter: Alex Rudyy The documentation for node auto-creation policies is absent in Broker docbook. As this feature was added in version 6.1.0 it would be beneficial for end-users to add corresponding documentation -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management
[
https://issues.apache.org/jira/browse/QPID-8124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8124:
-
Description:
When user is successfully authenticated, the user information in operational
log for checking management access is reported as <> for both Allowed
and Denied outcomes:
{noformat}
INFO [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied :
Access Management
INFO [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed :
Access Management
INFO [qtp1675859208-64] (q.m.m.open) - [mng:nyXoe7Io(admin@/127.0.0.1:45666)]
MNG-1007 : Open : User admin
{noformat}
As result, it is impossible to identify the principal name of authenticated
user in operational log when access is denied.
Thought, it is possible to get the principal name for "allowed" outcome by
looking into the following logs from the same thread, it would be beneficial to
print the real principal information in the log for Allowed outcome.
was:
When user is successfully authenticated, the user subject of operational log
for checking management access is reported as <> with both Allowed and
Denied outcomes:
{noformat}
INFO [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied :
Access Management
INFO [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed :
Access Management
INFO [qtp1675859208-64] (q.m.m.open) - [mng:nyXoe7Io(admin@/127.0.0.1:45666)]
MNG-1007 : Open : User admin
{noformat}
As result, it is impossible to identify the principal name of authenticated
user in operational log when access is denied.
Thought, it is possible to get the principal name for "allowed" outcome by
looking into the following logs from the same thread, it would be beneficial to
print the real principal information in the log for Allowed outcome.
> [Broker-J][REST] Sucessfully authenticated user is reported as <> in
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
>
> When user is successfully authenticated, the user information in operational
> log for checking management access is reported as <> for both
> Allowed and Denied outcomes:
> {noformat}
> INFO [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied :
> Access Management
> INFO [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed :
> Access Management
> INFO [qtp1675859208-64] (q.m.m.open) -
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated
> user in operational log when access is denied.
> Thought, it is possible to get the principal name for "allowed" outcome by
> looking into the following logs from the same thread, it would be beneficial
> to print the real principal information in the log for Allowed outcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management
Alex Rudyy created QPID-8124:
Summary: [Broker-J][REST] Sucessfully authenticated user is
reported as <> in ACL operational logs when checking access to
management
Key: QPID-8124
URL: https://issues.apache.org/jira/browse/QPID-8124
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0,
qpid-java-broker-7.0.2
Reporter: Alex Rudyy
When user is successfully authenticated, the user subject of operational log
for checking management access is reported as <> with both Allowed and
Denied outcomes:
{noformat}
INFO [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied :
Access Management
INFO [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed :
Access Management
INFO [qtp1675859208-64] (q.m.m.open) - [mng:nyXoe7Io(admin@/127.0.0.1:45666)]
MNG-1007 : Open : User admin
{noformat}
As result, it is impossible to identify the principal name of authenticated
user in operational log when access is denied.
Thought, it is possible to get the principal name for "allowed" outcome by
looking into the following logs from the same thread, it would be beneficial to
print the real principal information in the log for Allowed outcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8123: - Summary: [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x (was: [Broker-J] [BDB] Remove compile time dependency on Qpid JMS Client AMQP 0-x) > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8123) [Broker-J] [BDB] Remove compile time dependency on Qpid JMS Client AMQP 0-x
Keith Wall created QPID-8123: Summary: [Broker-J] [BDB] Remove compile time dependency on Qpid JMS Client AMQP 0-x Key: QPID-8123 URL: https://issues.apache.org/jira/browse/QPID-8123 Project: Qpid Issue Type: Test Components: Broker-J, Java Tests Reporter: Keith Wall Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-7873: Assignee: Keith Wall (was: Alex Rudyy) > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7873: - Status: Reviewable (was: In Progress) > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395227#comment-16395227 ] ASF subversion and git services commented on QPID-7873: --- Commit 7ce54800d597ad6438876ff04383386b0bb6732a 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=7ce5480 ] QPID-7873: [Broker-J] Do not clean-up delete actions on opening of message store > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8122) [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database charset is utf8mb4
[
https://issues.apache.org/jira/browse/QPID-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395162#comment-16395162
]
Keith Wall commented on QPID-8122:
--
That's true, I had forgotten that that was the reason the structure is so.
Removing the ability to store multiple parents would simplify the code and
side-step this issue.
> [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database
> charset is utf8mb4
>
>
> Key: QPID-8122
> URL: https://issues.apache.org/jira/browse/QPID-8122
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Environment: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04
>Reporter: Keith Wall
>Priority: Major
>
> With MariaDB 10.0.34 on Ubuntu 16.04 defaults its database character set type
> to {{utf8mb4}}.
> {noformat}
> MariaDB [qpid]> show variables like 'character_set_database';
> +++
> | Variable_name | Value |
> +++
> | character_set_database | utf8mb4 |
> +++
> 1 row in set (0.00 sec)
> {noformat}
> If I try and create a JDBC backed VHN, it fails with the following exception:
> {noformat}
> 2018-03-09 13:22:58,067 ERROR [Broker-Config]
> (o.a.q.s.u.ServerScopedRuntimeException) - Unable to open configuration tables
> java.sql.SQLSyntaxErrorException: (conn=173) Specified key was too long; max
> key length is 767 bytes
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:177)
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110)
> at
> org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228)
> at
> org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334)
> at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:386)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:300)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createConfiguredObjectHierarchyTable(AbstractJDBCConfigurationStore.java:497)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createOrOpenConfigurationStoreDatabase(AbstractJDBCConfigurationStore.java:448)
> {noformat}
> The primary key length of the QPID_CONFIGURED_OBJECT_HIERARCHY is too long in
> this character set mode.
> It seems other MariaDB packages on other distributions default to {{latin1}}
> which does not face this problem. Switching to {{latin1}} like so is a
> workaround:
> {noformat}
> ALTER DATABASE qpid CHARACTER SET latin1{noformat}
> However, this would mean that a characters appearing in configuration items
> outwith latin1 would be lost.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
qpid_proton Ruby Binding Leaking File Descriptors
Hi guys, thanks for developing the awesome qpid_proton ruby gem, we're using it on daily basis! However, recently we noticed following error in our server log: Too many open files - socket(2) for " 172.16.117.189 " port 5672 After some research it turns out that qpid_proton process is having increasingly more and more following file descriptors open: $ lsof -ap 108533 ruby 108533 miha 116u IPv4 562438 0t0 TCP 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 197u IPv4 561644 0t0 TCP 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 311u IPv4 560657 0t0 TCP 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 549u IPv4 565342 0t0 TCP 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 576u IPv4 565122 0t0 TCP 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 603u IPv4 565738 0t0 TCP 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 630u IPv4 563021 0t0 TCP 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 657u IPv4 568361 0t0 TCP 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 666u IPv4 563027 0t0 TCP 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 675u IPv4 567538 0t0 TCP 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 684u IPv4 567998 0t0 TCP 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 690u IPv4 574709 0t0 TCP 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 693u IPv4 578725 0t0 TCP 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 696u IPv4 576840 0t0 TCP 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 699u IPv4 577819 0t0 TCP 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 702u IPv4 582192 0t0 TCP 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 705u IPv4 582861 0t0 TCP 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 708u IPv4 577363 0t0 TCP 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 711u IPv4 578175 0t0 TCP 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 714u IPv4 587172 0t0 TCP 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) ruby 108533 miha 717u IPv4 584387 0t0 TCP 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) ... I think the CLOSE_WAIT status of file descriptor indicates that the TCP connection has already been closed, but the file descriptor wasn't closed. After 9 hours or so there are enough of such file descriptors for OS to complain about it. We did all we could to close connections gracefully: connection.container.stop connection.close connection = nil but nothing seems to help. A simple but expensive workaround is to manually invoke Ruby's garbage collection, but ideally `connection.close` would close the file descriptor. May I kindly ask you to look at this? Thank you and Best Regards, Miha PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0
[jira] [Commented] (QPID-8122) [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database charset is utf8mb4
[
https://issues.apache.org/jira/browse/QPID-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395092#comment-16395092
]
Rob Godfrey commented on QPID-8122:
---
This table seems like it was designed with the notion of children having
multiple parents in mind. Given we removed that capability there seems no
reason to have parent_type as part of the primary key. In fact maybe it is
simply better to remove this table altogether and move the parent_id field to
whichever table stores the objects themselves.
> [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database
> charset is utf8mb4
>
>
> Key: QPID-8122
> URL: https://issues.apache.org/jira/browse/QPID-8122
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Environment: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04
>Reporter: Keith Wall
>Priority: Major
>
> With MariaDB 10.0.34 on Ubuntu 16.04 defaults its database character set type
> to {{utf8mb4}}.
> {noformat}
> MariaDB [qpid]> show variables like 'character_set_database';
> +++
> | Variable_name | Value |
> +++
> | character_set_database | utf8mb4 |
> +++
> 1 row in set (0.00 sec)
> {noformat}
> If I try and create a JDBC backed VHN, it fails with the following exception:
> {noformat}
> 2018-03-09 13:22:58,067 ERROR [Broker-Config]
> (o.a.q.s.u.ServerScopedRuntimeException) - Unable to open configuration tables
> java.sql.SQLSyntaxErrorException: (conn=173) Specified key was too long; max
> key length is 767 bytes
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:177)
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110)
> at
> org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228)
> at
> org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334)
> at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:386)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:300)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createConfiguredObjectHierarchyTable(AbstractJDBCConfigurationStore.java:497)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createOrOpenConfigurationStoreDatabase(AbstractJDBCConfigurationStore.java:448)
> {noformat}
> The primary key length of the QPID_CONFIGURED_OBJECT_HIERARCHY is too long in
> this character set mode.
> It seems other MariaDB packages on other distributions default to {{latin1}}
> which does not face this problem. Switching to {{latin1}} like so is a
> workaround:
> {noformat}
> ALTER DATABASE qpid CHARACTER SET latin1{noformat}
> However, this would mean that a characters appearing in configuration items
> outwith latin1 would be lost.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8122) [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database charset is utf8mb4
[
https://issues.apache.org/jira/browse/QPID-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395085#comment-16395085
]
Keith Wall commented on QPID-8122:
--
MariaDB does support {{BINARY}} and {{VARBINARY}}
[https://mariadb.com/kb/en/library/data-types/]
The problematic statement the PRIMARY KEY of the following DDL:
{code:java}
stmt.execute("CREATE TABLE " + getConfiguredObjectHierarchyTableName()
+ " ( child_id VARCHAR(36) not null, parent_type varchar(255), parent_id
VARCHAR(36), PRIMARY KEY (child_id, parent_type))");{code}
{{utf8mb4}} uses a maximum of 4 bytes to store each Unicode character (it
allows Unicode supplementary characters), so I think MariaDB is computing the
index key storage requirement to be:
{code:java}
(36 * 4) + (255 * 4) = 1164{code}
This exceeds the 767 byte restriction.
We could change the {{child_id}} so that it is stored as a {{VARBINARY(16)}}
saving 20 bytes. This leaves 751 bytes for the storage of the {{parent_type}}.
We could opt to store the type as a {{VARCHAR(187)}} or a {{VARBINARY(751)}}
and, as Rob suggests, encode the UTF-8 ourselves.
We don't normally expect users to be inspecting the database underneath
Broker-J but if they needs to query these tables, perhaps for diagnostic
purposes, the MariaDB built ins {{UUID_TO_BIN()}} and {{BIN_TO_UUID()}} would
be convenient. Keeping the database knowing that the {{parent_type}} is text
would also help adhoc querying.
> [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database
> charset is utf8mb4
>
>
> Key: QPID-8122
> URL: https://issues.apache.org/jira/browse/QPID-8122
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Environment: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04
>Reporter: Keith Wall
>Priority: Major
>
> With MariaDB 10.0.34 on Ubuntu 16.04 defaults its database character set type
> to {{utf8mb4}}.
> {noformat}
> MariaDB [qpid]> show variables like 'character_set_database';
> +++
> | Variable_name | Value |
> +++
> | character_set_database | utf8mb4 |
> +++
> 1 row in set (0.00 sec)
> {noformat}
> If I try and create a JDBC backed VHN, it fails with the following exception:
> {noformat}
> 2018-03-09 13:22:58,067 ERROR [Broker-Config]
> (o.a.q.s.u.ServerScopedRuntimeException) - Unable to open configuration tables
> java.sql.SQLSyntaxErrorException: (conn=173) Specified key was too long; max
> key length is 767 bytes
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:177)
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110)
> at
> org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228)
> at
> org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334)
> at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:386)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:300)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createConfiguredObjectHierarchyTable(AbstractJDBCConfigurationStore.java:497)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createOrOpenConfigurationStoreDatabase(AbstractJDBCConfigurationStore.java:448)
> {noformat}
> The primary key length of the QPID_CONFIGURED_OBJECT_HIERARCHY is too long in
> this character set mode.
> It seems other MariaDB packages on other distributions default to {{latin1}}
> which does not face this problem. Switching to {{latin1}} like so is a
> workaround:
> {noformat}
> ALTER DATABASE qpid CHARACTER SET latin1{noformat}
> However, this would mean that a characters appearing in configuration items
> outwith latin1 would be lost.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #140: PROTON-1638, PROTON-1728: Reorganize the source tree
Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton/pull/140 I gave things a skim over, changes seemed reasonable from my doesnt-do-cmake-etc perspective. Noting for later reference: this builds on / incorporates WIP from #136 and #138. --- - 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
[ https://issues.apache.org/jira/browse/PROTON-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395031#comment-16395031 ] ASF GitHub Bot commented on PROTON-1638: Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton/pull/140 I gave things a skim over, changes seemed reasonable from my doesnt-do-cmake-etc perspective. Noting for later reference: this builds on / incorporates WIP from #136 and #138. > 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 >Assignee: Justin Ross >Priority: Major > > 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 (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
