[jira] [Commented] (PROTON-439) Support for dynamic reply-to address in Messenger
[ https://issues.apache.org/jira/browse/PROTON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837747#comment-13837747 ] Ted Ross commented on PROTON-439: - As of the last commit (1547100), this feature works as I expect it to. Support for dynamic reply-to address in Messenger - Key: PROTON-439 URL: https://issues.apache.org/jira/browse/PROTON-439 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ted Ross Assignee: Rafael H. Schloming Fix For: 0.6 Messenger has no support for creating dynamic receivers for reply-to addresses. Please refer to the following email thread for prior discussion on the topic. http://qpid.2158936.n2.nabble.com/Proton-Messenger-and-the-Request-Response-pattern-tp7586653.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-200) [Proton-c] Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838055#comment-13838055 ] ASF subversion and git services commented on PROTON-200: Commit 1547534 from [~kgiusti] in branch 'proton/trunk' [ https://svn.apache.org/r1547534 ] PROTON-200: Java implementation of credit scheduler [Proton-c] Credit distribution by messenger is not balanced across all links Key: PROTON-200 URL: https://issues.apache.org/jira/browse/PROTON-200 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.6 Attachments: proton-200.patch, upstream-credit.patch The method used to distribute credit to receiving links may lead to starvation when the number of receiving links is the available credit. The distribution algorithm always starts with the same link - see messenger.c::pn_messenger_flow() -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-200) [Proton-c] Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-200. --- Resolution: Fixed [Proton-c] Credit distribution by messenger is not balanced across all links Key: PROTON-200 URL: https://issues.apache.org/jira/browse/PROTON-200 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.6 Attachments: proton-200.patch, upstream-credit.patch The method used to distribute credit to receiving links may lead to starvation when the number of receiving links is the available credit. The distribution algorithm always starts with the same link - see messenger.c::pn_messenger_flow() -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-445) Binding installation ignores prefix
[ https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838151#comment-13838151 ] ASF subversion and git services commented on PROTON-445: Commit 1547577 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1547577 ] PROTON-445: Python install now honors CMAKE_INSTALL_PREFIX The language bindings will now honor this prefix, both the default value and a user-specified value. Developers can override it, though, by specifying PYTHON_INSTALL_PREFIX at the command line as well. This will allow for installing the Python bindings to a different directory if so desired. Binding installation ignores prefix --- Key: PROTON-445 URL: https://issues.apache.org/jira/browse/PROTON-445 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Justin Ross Attachments: what-a-mess.txt It allows you *prepend* to the install prefix, but it gives you no way afaict to actually change the prefix. This is the opposite of nice. If you set a prefix for your build *and* you try to get your bindings slotted in with them, via DESTDIR, you get this: # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source # make install DESTDIR=/opt/myplace /opt/myplace/usr/lib/python/*python files* /opt/myplace/opt/myplace/lib/*c files* ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from CMAKE_INSTALL_PREFIX What it is doing now is simply abuse of DESTDIR. DESTDIR is intended to be a mechanism for staged installs (packaging systems use this), and it cannot function correctly as an override for prefix. http://www.gnu.org/prep/standards/html_node/DESTDIR.html My proposed solution to this is to stop this madness: make the binding install honor CMAKE_INSTALL_PREFIX. Let the developer be responsible for choosing the right location for his or her distribution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-445) Binding installation ignores prefix
[ https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838153#comment-13838153 ] ASF subversion and git services commented on PROTON-445: Commit 1547578 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1547578 ] PROTON-445: Perl install now honors CMAKE_INSTALL_PREFIX The language bindings will now honor this prefix, both the default value and a user-specified value. Developers can override it, though, by specifying PERL_INSTALL_PREFIX at the command line as well. This will allow for installing the Perl bindings to a different directory if so desired. Also updated the installation pieces in CMake to simplify it. Binding installation ignores prefix --- Key: PROTON-445 URL: https://issues.apache.org/jira/browse/PROTON-445 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Justin Ross Attachments: what-a-mess.txt It allows you *prepend* to the install prefix, but it gives you no way afaict to actually change the prefix. This is the opposite of nice. If you set a prefix for your build *and* you try to get your bindings slotted in with them, via DESTDIR, you get this: # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source # make install DESTDIR=/opt/myplace /opt/myplace/usr/lib/python/*python files* /opt/myplace/opt/myplace/lib/*c files* ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from CMAKE_INSTALL_PREFIX What it is doing now is simply abuse of DESTDIR. DESTDIR is intended to be a mechanism for staged installs (packaging systems use this), and it cannot function correctly as an override for prefix. http://www.gnu.org/prep/standards/html_node/DESTDIR.html My proposed solution to this is to stop this madness: make the binding install honor CMAKE_INSTALL_PREFIX. Let the developer be responsible for choosing the right location for his or her distribution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-464) Interpolate CMAKE_INSTALL_PREFIX into Ruby install directory.
[ https://issues.apache.org/jira/browse/PROTON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838154#comment-13838154 ] ASF subversion and git services commented on PROTON-464: Commit 1547579 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1547579 ] PROTON-464: Install Ruby bindings to install prefix if specified. If the user provides a CMAKE_INSTALL_PREFIX on the command line, then that directory is used to install the Ruby language bindings. If no install prefix is specified then the Ruby bindings honor the directory specified by the Ruby VM itself. Interpolate CMAKE_INSTALL_PREFIX into Ruby install directory. - Key: PROTON-464 URL: https://issues.apache.org/jira/browse/PROTON-464 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce By checking the 'prefix' value from RbConfig::CONFIG, we can then take the sitearch and sitelib paths and substitute that prefix value for what's given by thye user with CMAKE_INSTALL_PREFIX. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-445) Binding installation ignores prefix
[ https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838226#comment-13838226 ] ASF subversion and git services commented on PROTON-445: Commit 1547597 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1547597 ] PROTON-445: PHP install now honors the install prefix. If the install prefix is not /usr then the INI directory is placed below it. This is to accomodate a system install as opposed to a developer install. Binding installation ignores prefix --- Key: PROTON-445 URL: https://issues.apache.org/jira/browse/PROTON-445 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Justin Ross Fix For: 0.6 Attachments: what-a-mess.txt It allows you *prepend* to the install prefix, but it gives you no way afaict to actually change the prefix. This is the opposite of nice. If you set a prefix for your build *and* you try to get your bindings slotted in with them, via DESTDIR, you get this: # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source # make install DESTDIR=/opt/myplace /opt/myplace/usr/lib/python/*python files* /opt/myplace/opt/myplace/lib/*c files* ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from CMAKE_INSTALL_PREFIX What it is doing now is simply abuse of DESTDIR. DESTDIR is intended to be a mechanism for staged installs (packaging systems use this), and it cannot function correctly as an override for prefix. http://www.gnu.org/prep/standards/html_node/DESTDIR.html My proposed solution to this is to stop this madness: make the binding install honor CMAKE_INSTALL_PREFIX. Let the developer be responsible for choosing the right location for his or her distribution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-445) Binding installation ignores prefix
[ https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-445. - Resolution: Fixed Fix Version/s: 0.6 Binding installation ignores prefix --- Key: PROTON-445 URL: https://issues.apache.org/jira/browse/PROTON-445 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Justin Ross Fix For: 0.6 Attachments: what-a-mess.txt It allows you *prepend* to the install prefix, but it gives you no way afaict to actually change the prefix. This is the opposite of nice. If you set a prefix for your build *and* you try to get your bindings slotted in with them, via DESTDIR, you get this: # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source # make install DESTDIR=/opt/myplace /opt/myplace/usr/lib/python/*python files* /opt/myplace/opt/myplace/lib/*c files* ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from CMAKE_INSTALL_PREFIX What it is doing now is simply abuse of DESTDIR. DESTDIR is intended to be a mechanism for staged installs (packaging systems use this), and it cannot function correctly as an override for prefix. http://www.gnu.org/prep/standards/html_node/DESTDIR.html My proposed solution to this is to stop this madness: make the binding install honor CMAKE_INSTALL_PREFIX. Let the developer be responsible for choosing the right location for his or her distribution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
Timothy Bish created PROTON-474: --- Summary: Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer Key: PROTON-474 URL: https://issues.apache.org/jira/browse/PROTON-474 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.5 Reporter: Timothy Bish Fix For: 0.6 The inbound message transformation of AMQP message to JMS message incorrectly sets the JMSExpiration to message TTL which is defined in milliseconds while the JMSExpiration value is a sum of the Message Timestamp and the producers TTL. The transformation should probably map the message creation time + the TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
[ https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-474: Attachment: JMSExpiration-patch.txt Proposed patch for this issue. Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer --- Key: PROTON-474 URL: https://issues.apache.org/jira/browse/PROTON-474 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.5 Reporter: Timothy Bish Fix For: 0.6 Attachments: JMSExpiration-patch.txt The inbound message transformation of AMQP message to JMS message incorrectly sets the JMSExpiration to message TTL which is defined in milliseconds while the JMSExpiration value is a sum of the Message Timestamp and the producers TTL. The transformation should probably map the message creation time + the TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.1#6144)
