[jira] [Resolved] (PROTON-1933) [go] error from ill-formed message is not reported
[ https://issues.apache.org/jira/browse/PROTON-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1933. - Resolution: Fixed > [go] error from ill-formed message is not reported > -- > > Key: PROTON-1933 > URL: https://issues.apache.org/jira/browse/PROTON-1933 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > If an invalid (e.g. truncated) message is received on an > electron.Receiver.Receive() it returns (nil, nil), instead of an error. The > error is detected by the proton library, it should be returned by Receive() -- 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-1933) [go] error from ill-formed message is not reported
[ https://issues.apache.org/jira/browse/PROTON-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647134#comment-16647134 ] Alan Conway commented on PROTON-1933: - Seems to be fixed as a side effect of fixes up to 4a9f3b98 * PROTON-1910: [go] move message encode/decode to handler thread > [go] error from ill-formed message is not reported > -- > > Key: PROTON-1933 > URL: https://issues.apache.org/jira/browse/PROTON-1933 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > If an invalid (e.g. truncated) message is received on an > electron.Receiver.Receive() it returns (nil, nil), instead of an error. The > error is detected by the proton library, it should be returned by Receive() -- 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] [Resolved] (PROTON-1953) [go] occasional client/server hang with high volume of messages
[ https://issues.apache.org/jira/browse/PROTON-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1953. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > [go] occasional client/server hang with high volume of messages > --- > > Key: PROTON-1953 > URL: https://issues.apache.org/jira/browse/PROTON-1953 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > In long runs of rapid message exchange the client and server sometimes hang. -- 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-1956) [go] server does not close transport on unexpected disconnect
[ https://issues.apache.org/jira/browse/PROTON-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647124#comment-16647124 ] Alan Conway commented on PROTON-1956: - Fixed by: 2a84494c * PROTON-1956: [go] server does not close transport on unexpected disconnect > [go] server does not close transport on unexpected disconnect > - > > Key: PROTON-1956 > URL: https://issues.apache.org/jira/browse/PROTON-1956 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > A Go server does not always close the transport on some kinds of unexpected > disconnect, > in particular a connect with immediate disconnect (no AMQP protocol exchange) > does causes the server to hang. -- 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] [Resolved] (PROTON-1956) [go] server does not close transport on unexpected disconnect
[ https://issues.apache.org/jira/browse/PROTON-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1956. - Resolution: Fixed > [go] server does not close transport on unexpected disconnect > - > > Key: PROTON-1956 > URL: https://issues.apache.org/jira/browse/PROTON-1956 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > A Go server does not always close the transport on some kinds of unexpected > disconnect, > in particular a connect with immediate disconnect (no AMQP protocol exchange) > does causes the server to hang. -- 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-1953) [go] occasional client/server hang with high volume of messages
[ https://issues.apache.org/jira/browse/PROTON-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647127#comment-16647127 ] Alan Conway commented on PROTON-1953: - Fixed by: 486fbaf0 * PROTON-1953: [go] occasional client/server hang with high volume of messages > [go] occasional client/server hang with high volume of messages > --- > > Key: PROTON-1953 > URL: https://issues.apache.org/jira/browse/PROTON-1953 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > In long runs of rapid message exchange the client and server sometimes hang. -- 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] [Resolved] (PROTON-1955) [go] incorrect conversion between Go time and AMQP time
[ https://issues.apache.org/jira/browse/PROTON-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1955. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > [go] incorrect conversion between Go time and AMQP time > --- > > Key: PROTON-1955 > URL: https://issues.apache.org/jira/browse/PROTON-1955 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.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] (PROTON-1955) [go] incorrect conversion between Go time and AMQP time
[ https://issues.apache.org/jira/browse/PROTON-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647122#comment-16647122 ] Alan Conway commented on PROTON-1955: - Fixed by: ccaeaa0c * PROTON-1955: [go] incorrect conversion between Go time and AMQP time > [go] incorrect conversion between Go time and AMQP time > --- > > Key: PROTON-1955 > URL: https://issues.apache.org/jira/browse/PROTON-1955 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.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] (PROTON-1954) [go] Container should default to random container-id
[ https://issues.apache.org/jira/browse/PROTON-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647121#comment-16647121 ] Alan Conway commented on PROTON-1954: - Fixed by: c2491078 * PROTON-1954: [go] Container should default to random container-id > [go] Container should default to random container-id > > > Key: PROTON-1954 > URL: https://issues.apache.org/jira/browse/PROTON-1954 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.27.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] [Resolved] (PROTON-1954) [go] Container should default to random container-id
[ https://issues.apache.org/jira/browse/PROTON-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1954. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > [go] Container should default to random container-id > > > Key: PROTON-1954 > URL: https://issues.apache.org/jira/browse/PROTON-1954 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.27.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] (PROTON-1910) Profiling indicates that cgo becomes a bottleneck during scale testing of electron
[ https://issues.apache.org/jira/browse/PROTON-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647119#comment-16647119 ] Alan Conway commented on PROTON-1910: - This commit implements the strategy outlined above: moving all message encode/decode into the proton goroutine and re-using a single pn_message_t per connection to save some setup time and cache some data structures. I see about 30% improvement in performance with this fix: 4a9f3b98 * PROTON-1910: [go] move message encode/decode to handler thread The Go client is still slower than I would like compared to the C client, further optimization work is needed. > Profiling indicates that cgo becomes a bottleneck during scale testing of > electron > -- > > Key: PROTON-1910 > URL: https://issues.apache.org/jira/browse/PROTON-1910 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.24.0 >Reporter: Aaron Smith >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > While performing scale testing, detailed profiling of Go test clients showed > that >95% of the execution time can be devoted to the cgo call. The issues > seems to be related on sends to the NewMessage() call. For receives, the > bottleneck is both NewMessage() and the call to actually receive the message. > > > This behavior is not unexpected as CGO is a well-known bottleneck. Would it > be possible to have a NewMessage() call that return multiple messages and a > recv call that took an "At most" argument. i.e. recv(10) would receive 10 or > fewer messages that might be waiting in the queue. Also, it would be nice to > be able to trade latency for throughput in that the callback wasn't triggered > until N messages were recieved (with timeout) -- 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] [Resolved] (PROTON-1910) Profiling indicates that cgo becomes a bottleneck during scale testing of electron
[ https://issues.apache.org/jira/browse/PROTON-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1910. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > Profiling indicates that cgo becomes a bottleneck during scale testing of > electron > -- > > Key: PROTON-1910 > URL: https://issues.apache.org/jira/browse/PROTON-1910 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.24.0 >Reporter: Aaron Smith >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > While performing scale testing, detailed profiling of Go test clients showed > that >95% of the execution time can be devoted to the cgo call. The issues > seems to be related on sends to the NewMessage() call. For receives, the > bottleneck is both NewMessage() and the call to actually receive the message. > > > This behavior is not unexpected as CGO is a well-known bottleneck. Would it > be possible to have a NewMessage() call that return multiple messages and a > recv call that took an "At most" argument. i.e. recv(10) would receive 10 or > fewer messages that might be waiting in the queue. Also, it would be nice to > be able to trade latency for throughput in that the callback wasn't triggered > until N messages were recieved (with timeout) -- 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] [Resolved] (PROTON-1951) [go] Server connection fails to authenticate if Server() is not first
[ https://issues.apache.org/jira/browse/PROTON-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1951. - Resolution: Fixed > [go] Server connection fails to authenticate if Server() is not first > - > > Key: PROTON-1951 > URL: https://issues.apache.org/jira/browse/PROTON-1951 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > If a server connection is created where the Server() option comes after SASL > options in the option list, then SASL is not configured correctly and the > server hangs during authentication. > Server connections created by Connection.Accept() suffer from this problem. -- 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-1951) [go] Server connection fails to authenticate if Server() is not first
[ https://issues.apache.org/jira/browse/PROTON-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647115#comment-16647115 ] Alan Conway commented on PROTON-1951: - Fixed by mis-labeled commit: 55b27351 * PROTON-1952: [go] Server connection fails to authenticate > [go] Server connection fails to authenticate if Server() is not first > - > > Key: PROTON-1951 > URL: https://issues.apache.org/jira/browse/PROTON-1951 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > If a server connection is created where the Server() option comes after SASL > options in the option list, then SASL is not configured correctly and the > server hangs during authentication. > Server connections created by Connection.Accept() suffer from this problem. -- 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] [Resolved] (DISPATCH-1126) ERROR Attempt to attach too many inter-router links for priority sheaf.
[ https://issues.apache.org/jira/browse/DISPATCH-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1126. - Resolution: Fixed Fix Version/s: 1.4.0 > ERROR Attempt to attach too many inter-router links for priority sheaf. > --- > > Key: DISPATCH-1126 > URL: https://issues.apache.org/jira/browse/DISPATCH-1126 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 > Environment: Fedora 28 > * Three router network in linear arrangement A - B - C. > * B has a listener; A and C connect to it > >Reporter: Chuck Rolke >Assignee: michael goulish >Priority: Major > Fix For: 1.4.0 > > Attachments: taj-GRN.log > > > Some state probably not cleaned up when router connections are lost. 10 > messages > (error) Attempt to attach too many inter-router links for priority sheaf. > appear when routers reconnect. > Start the network. Then kill routers A and C and restart them. Router B > prints the messages. > Log file attached -- 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] (DISPATCH-1096) support AMQP prioritized messages
[ https://issues.apache.org/jira/browse/DISPATCH-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647057#comment-16647057 ] ASF GitHub Bot commented on DISPATCH-1096: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/384 > support AMQP prioritized messages > - > > Key: DISPATCH-1096 > URL: https://issues.apache.org/jira/browse/DISPATCH-1096 > Project: Qpid Dispatch > Issue Type: New Feature >Reporter: michael goulish >Assignee: michael goulish >Priority: Major > Fix For: 1.4.0 > > > Detect priority info from message header in the router code. > Create separate inter-router links for the various priorities. > Per connection (i.e. not globally across the router) service high-priority > inter-router links before low priority links. -- 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-dispatch pull request #384: DISPATCH-1096 - priority sheaf cleanup bug
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/384 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647047#comment-16647047
]
ASF GitHub Bot commented on DISPATCH-1110:
--
Github user ganeshmurthy closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/390
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.4.0
>
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its own.
> {noformat}
> ... (plenty of 65550-sized frames R->C)
> R->C 5976 3.454766::1 ::1 AMQP65550
> R->C 5977 3.454775::1 ::1 AMQP65550
> R->C 5978 3.454783::1 ::1 AMQP48171
> C->R 5982 3.529881::1 ::1 AMQP115 disposition
> C->R 5984 7.530704::1 ::1 AMQP94 (empty)
> C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
> ...{noformat}
> There are no errors to be seen in the router logs other than when the
> consuming client is killed owing to the test timeout.
> {noformat}
> ...
> 2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
> ::1:amqp from ::1:37262
> 2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from
> ::1:37262 (to ::1:amqp) failed: amqp:connection:framing-error connection
> aborted
> {noformat}
> The reproducer is not very tight on this, and the error occurs about 50% of
> the time on my hardware.
--
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-dispatch pull request #390: DISPATCH-1110 - Added code to synchronously...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/390 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1110.
-
Resolution: Fixed
Fix Version/s: 1.4.0
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.4.0
>
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its own.
> {noformat}
> ... (plenty of 65550-sized frames R->C)
> R->C 5976 3.454766::1 ::1 AMQP65550
> R->C 5977 3.454775::1 ::1 AMQP65550
> R->C 5978 3.454783::1 ::1 AMQP48171
> C->R 5982 3.529881::1 ::1 AMQP115 disposition
> C->R 5984 7.530704::1 ::1 AMQP94 (empty)
> C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
> ...{noformat}
> There are no errors to be seen in the router logs other than when the
> consuming client is killed owing to the test timeout.
> {noformat}
> ...
> 2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
> ::1:amqp from ::1:37262
> 2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from
> ::1:37262 (to ::1:amqp) failed: amqp:connection:framing-error connection
> aborted
> {noformat}
> The reproducer is not very tight on this, and the error occurs about 50% of
> the time on my hardware.
--
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] (DISPATCH-1144) Improve overview and getting started doc
[ https://issues.apache.org/jira/browse/DISPATCH-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646846#comment-16646846 ] ASF GitHub Bot commented on DISPATCH-1144: -- GitHub user bhardesty opened a pull request: https://github.com/apache/qpid-dispatch/pull/391 DISPATCH-1144: Improve overview and getting started doc Made a number of improvements to the introductory and getting started doc to make it easier for users to get up and running quickly: * Modify the dir structure under ../docs/books to better enable writing "modular" content * Move the "Theory of Operation" content to the applicable chapters later in the doc * Add new "Overview" content to introduce just the basic, most important concepts necessary to get started with Dispatch Router * Modify "Getting started" to cover a simple "hello world" type scenario (run a single router with the default config, and distribute some test messages between two clients) You can merge this pull request into a Git repository by running: $ git pull https://github.com/bhardesty/qpid-dispatch improve-overview Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/391.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 #391 commit cdc07a15c76529c185e555c8261a08bce0679c29 Author: Ben Hardesty Date: 2018-08-20T16:41:32Z Change doc dir structure for mod docs commit bb7b0938562d911649e39ac6f6d232306fc9b647 Author: Ben Hardesty Date: 2018-08-20T16:54:01Z Add underscore to common and images dirs commit a6cfaa7a58a005886cd87f9db83e3512f765d0fd Author: Ben Hardesty Date: 2018-08-20T16:55:40Z Remove old symlinks commit ebbae8ebf51de76a32b74e5496f59a8a7cd75911 Author: Ben Hardesty Date: 2018-08-24T20:28:10Z Create dirs for modules and assemblies, create overview assembly, create modules for overview commit 9bc090c135f6fe0cb8fd58c02f4f0f7457b6abda Author: Ben Hardesty Date: 2018-08-24T20:36:21Z Update to message routing module commit 7321a9a965f8c024c9cc9afa28251489813077d4 Author: Ben Hardesty Date: 2018-08-27T21:01:53Z Misc updates, add router security and routing modules commit ce54b05f1fd03e1fcfb8cfca3419fed4960debd7 Author: Ben Hardesty Date: 2018-08-28T15:43:44Z Add module on router management, update amqp overview module commit d68767ef07c3cee4af1d69441d7b170ad52008db Author: Ben Hardesty Date: 2018-10-08T19:27:24Z Add add'l resources and move theory of operation content to each applicable section commit 3e4383f2ae72d7ae6090f7533c1e2a369a0dc073 Author: Ben Hardesty Date: 2018-10-10T21:18:49Z Update getting started > Improve overview and getting started doc > > > Key: DISPATCH-1144 > URL: https://issues.apache.org/jira/browse/DISPATCH-1144 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > Improve the Dispatch Router doc so that a user can quickly get up to speed > and get started with the router. -- 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-dispatch pull request #391: DISPATCH-1144: Improve overview and getting...
GitHub user bhardesty opened a pull request: https://github.com/apache/qpid-dispatch/pull/391 DISPATCH-1144: Improve overview and getting started doc Made a number of improvements to the introductory and getting started doc to make it easier for users to get up and running quickly: * Modify the dir structure under ../docs/books to better enable writing "modular" content * Move the "Theory of Operation" content to the applicable chapters later in the doc * Add new "Overview" content to introduce just the basic, most important concepts necessary to get started with Dispatch Router * Modify "Getting started" to cover a simple "hello world" type scenario (run a single router with the default config, and distribute some test messages between two clients) You can merge this pull request into a Git repository by running: $ git pull https://github.com/bhardesty/qpid-dispatch improve-overview Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/391.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 #391 commit cdc07a15c76529c185e555c8261a08bce0679c29 Author: Ben Hardesty Date: 2018-08-20T16:41:32Z Change doc dir structure for mod docs commit bb7b0938562d911649e39ac6f6d232306fc9b647 Author: Ben Hardesty Date: 2018-08-20T16:54:01Z Add underscore to common and images dirs commit a6cfaa7a58a005886cd87f9db83e3512f765d0fd Author: Ben Hardesty Date: 2018-08-20T16:55:40Z Remove old symlinks commit ebbae8ebf51de76a32b74e5496f59a8a7cd75911 Author: Ben Hardesty Date: 2018-08-24T20:28:10Z Create dirs for modules and assemblies, create overview assembly, create modules for overview commit 9bc090c135f6fe0cb8fd58c02f4f0f7457b6abda Author: Ben Hardesty Date: 2018-08-24T20:36:21Z Update to message routing module commit 7321a9a965f8c024c9cc9afa28251489813077d4 Author: Ben Hardesty Date: 2018-08-27T21:01:53Z Misc updates, add router security and routing modules commit ce54b05f1fd03e1fcfb8cfca3419fed4960debd7 Author: Ben Hardesty Date: 2018-08-28T15:43:44Z Add module on router management, update amqp overview module commit d68767ef07c3cee4af1d69441d7b170ad52008db Author: Ben Hardesty Date: 2018-10-08T19:27:24Z Add add'l resources and move theory of operation content to each applicable section commit 3e4383f2ae72d7ae6090f7533c1e2a369a0dc073 Author: Ben Hardesty Date: 2018-10-10T21:18:49Z Update getting started --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1121) qd_parse_as_(u)int() fails to detect over/underflow of 32bit integers
[ https://issues.apache.org/jira/browse/DISPATCH-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1121. -- Resolution: Fixed > qd_parse_as_(u)int() fails to detect over/underflow of 32bit integers > - > > Key: DISPATCH-1121 > URL: https://issues.apache.org/jira/browse/DISPATCH-1121 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 1.3.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.4.0 > > > Attempting to parse a number that is out of range for a 32bit value will not > set the parse error flag. -- 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] (DISPATCH-1121) qd_parse_as_(u)int() fails to detect over/underflow of 32bit integers
[ https://issues.apache.org/jira/browse/DISPATCH-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646830#comment-16646830 ] ASF GitHub Bot commented on DISPATCH-1121: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/378 > qd_parse_as_(u)int() fails to detect over/underflow of 32bit integers > - > > Key: DISPATCH-1121 > URL: https://issues.apache.org/jira/browse/DISPATCH-1121 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 1.3.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.4.0 > > > Attempting to parse a number that is out of range for a 32bit value will not > set the parse error flag. -- 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-dispatch pull request #378: DISPATCH-1121: Set the parse error flag on ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/378 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1144) Improve overview and getting started doc
Ben Hardesty created DISPATCH-1144: -- Summary: Improve overview and getting started doc Key: DISPATCH-1144 URL: https://issues.apache.org/jira/browse/DISPATCH-1144 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Reporter: Ben Hardesty Assignee: Ben Hardesty Improve the Dispatch Router doc so that a user can quickly get up to speed and get started with the router. -- 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-1956) [go] server does not close transport on unexpected disconnect
Alan Conway created PROTON-1956: --- Summary: [go] server does not close transport on unexpected disconnect Key: PROTON-1956 URL: https://issues.apache.org/jira/browse/PROTON-1956 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Assignee: Alan Conway A Go server does not always close the transport on some kinds of unexpected disconnect, in particular a connect with immediate disconnect (no AMQP protocol exchange) does causes the server to hang. -- 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-1955) [go] incorrect conversion between Go time and AMQP time
Alan Conway created PROTON-1955: --- Summary: [go] incorrect conversion between Go time and AMQP time Key: PROTON-1955 URL: https://issues.apache.org/jira/browse/PROTON-1955 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Assignee: Alan Conway -- 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-1954) [go] Container should default to random container-id
Alan Conway created PROTON-1954: --- Summary: [go] Container should default to random container-id Key: PROTON-1954 URL: https://issues.apache.org/jira/browse/PROTON-1954 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Assignee: Alan Conway -- 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-1953) [go] occasional client/server hang with high volume of messages
Alan Conway created PROTON-1953: --- Summary: [go] occasional client/server hang with high volume of messages Key: PROTON-1953 URL: https://issues.apache.org/jira/browse/PROTON-1953 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Assignee: Alan Conway In long runs of rapid message exchange the client and server sometimes hang. -- 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] [Resolved] (QPIDJMS-416) Move protocol processing work into the netty event loop thread
[ https://issues.apache.org/jira/browse/QPIDJMS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-416. -- Resolution: Fixed > Move protocol processing work into the netty event loop thread > -- > > Key: QPIDJMS-416 > URL: https://issues.apache.org/jira/browse/QPIDJMS-416 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.38.0 > > > Currently the protocol specific processing is handled in its own single > threaded executor which creates a performance drop as reads and writes are > queued into Netty for handling. We can achieve a significant performance > boost by handling all the protocol work inside the Netty event loop and not > hopping between threads as we do now. > This requires some refactoring of connect and shutdown logic and some > safeguards around all callbacks in the transport to ensure that we always > operate on the event loop and not one on a client thread. -- 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] (DISPATCH-1143) Connection-scoped link routes
Ken Giusti created DISPATCH-1143: Summary: Connection-scoped link routes Key: DISPATCH-1143 URL: https://issues.apache.org/jira/browse/DISPATCH-1143 Project: Qpid Dispatch Issue Type: New Feature Reporter: Ken Giusti Assignee: Ken Giusti A new type of link route that exists only as long as the connection over which it has been created remains open. The new link route is automatically bound to that connection (cannot specify a different container-id nor connection). Once the connection closes the link route's configuration vanishes. More detail TBA -- 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-1952) Add possibility to set link-credit in proton receiver API
[ https://issues.apache.org/jira/browse/PROTON-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1952: --- Description: In the amqp standard, [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] is defined as: "the current maximum legal amount that the delivery-count can be increased by". Only the receiver can set its value. In the current proton API, we can only add to the link-credit. We cannot set it (our need is to set it to a value less than the actual link-credit). As to why we need this, we are trying to implement an asynchronous get with timeout (by returning a std::future). I understand that in the amqp standard, there are 2 supported modes of delivery, and async get with timeout is not mentioned: * [Synchronous get (with/without timeout)|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] * [Asynchronous notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] Therefore, we're implementing it for its convenience to us (the client receives the response/exception in his thread). Problem arises when we start having timeouts. Briefly (I can give you more details here if you want), having the ability to set the link-credit to a lower value would facilitate our lives. was: In the amqp standard, [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] is defined as: "the current maximum legal amount that the delivery-count can be increased by". Only the receiver can set its value. In the current proton API, we can only add to the link-credit. We cannot set it (our need is to set it to a value less than the actual link-credit). As to why we need this, we are trying to implement an asynchronous get with timeout (by returning a std::future). I understand that in the amqp standard, there are 2 supported modes of delivery, and async get with timeout is not mentioned: * [Synchronous get (with/without timeout)|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] * [Asynchronous notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] Therefore, we're implementing it for its convenience to us (the client receives the response/exception in his thread). Problem arises when we start having timeouts. Briefly (I can give you more details here if you want), having the ability to set the link-credit to a lower value would facilitate our lives. > Add possibility to set link-credit in proton receiver API > - > > Key: PROTON-1952 > URL: https://issues.apache.org/jira/browse/PROTON-1952 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > > In the amqp standard, > [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] > is defined as: "the current maximum legal amount that the delivery-count can > be increased by". Only the receiver can set its value. > In the current proton API, we can only add to the link-credit. We cannot set > it (our need is to set it to a value less than the actual link-credit). > As to why we need this, we are trying to implement an asynchronous get with > timeout (by returning a std::future). > I understand that in the amqp standard, there are 2 supported modes of > delivery, and async get with timeout is not mentioned: > * [Synchronous get (with/without > timeout)|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] > > * [Asynchronous > notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] > Therefore, we're implementing it for its convenience to us (the client > receives the response/exception in his thread). > Problem arises when we start having timeouts. Briefly (I can give you more > details here if you want), having the ability to set the link-credit to a > lower value would facilitate our lives. -- 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-1952) Add possibility to set link-credit in proton receiver API
[ https://issues.apache.org/jira/browse/PROTON-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1952: --- Description: In the amqp standard, [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] is defined as: "the current maximum legal amount that the delivery-count can be increased by". Only the receiver can set its value. In the current proton API, we can only add to the link-credit. We cannot set it (our need is to set it to a value less than the actual link-credit). As to why we need this, we are trying to implement an asynchronous get with timeout (by returning a std::future). I understand that in the amqp standard, there are 2 supported modes of delivery, and async get with timeout is not mentioned: * [Synchronous get (with/without timeout)|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] * [Asynchronous notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] Therefore, we're implementing it for its convenience to us (the client receives the response/exception in his thread). Problem arises when we start having timeouts. Briefly (I can give you more details here if you want), having the ability to set the link-credit to a lower value would facilitate our lives. was: In the amqp standard, [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] is defined as: "the current maximum legal amount that the delivery-count can be increased by". Only the receiver can set its value. In the current proton API, we can only add to the link-credit. We cannot set it (our need is to set it to a value less than the actual link-credit). As to why we need this, we are trying to implement an asynchronous get with timeout (by returning a std::future). I understand that in the amqp standard, there are 2 supported modes of delivery, and async get with timeout is not mentioned: * [Synchronous get with timeout|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] * [Asynchronous notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] Therefore, we're implementing it for its convenience to us (the client receives the response/exception in his thread). Problem arises when we start having timeouts. Briefly (I can give you more details here if you want), having the ability to set the link-credit to a lower value would facilitate our lives. > Add possibility to set link-credit in proton receiver API > - > > Key: PROTON-1952 > URL: https://issues.apache.org/jira/browse/PROTON-1952 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > > In the amqp standard, > [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] > is defined as: "the current maximum legal amount that the delivery-count can > be increased by". Only the receiver can set its value. > In the current proton API, we can only add to the link-credit. We cannot set > it (our need is to set it to a value less than the actual link-credit). > As to why we need this, we are trying to implement an asynchronous get with > timeout (by returning a std::future). > I understand that in the amqp standard, there are 2 supported modes of > delivery, and async get with timeout is not mentioned: > * [Synchronous get (with/without > timeout)|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] > > * [Asynchronous > notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] > Therefore, we're implementing it for its convenience to us (the client > receives the response/exception in his thread). > Problem arises when we start having timeouts. Briefly (I can give you more > details here if you want), having the ability to set the link-credit to a > lower value would facilitate our lives. -- 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-1952) Add possibility to set link-credit in proton receiver API
[ https://issues.apache.org/jira/browse/PROTON-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1952: --- Description: In the amqp standard, [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] is defined as: "the current maximum legal amount that the delivery-count can be increased by". Only the receiver can set its value. In the current proton API, we can only add to the link-credit. We cannot set it (our need is to set it to a value less than the actual link-credit). As to why we need this, we are trying to implement an asynchronous get with timeout (by returning a std::future). I understand that in the amqp standard, there are 2 supported modes of delivery, and async get with timeout is not mentioned: * [Synchronous get with timeout|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] * [Asynchronous notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] Therefore, we're implementing it for its convenience to us (the client receives the response/exception in his thread). Problem arises when we start having timeouts. Briefly (I can give you more details here if you want), having the ability to set the link-credit to a lower value would facilitate our lives. > Add possibility to set link-credit in proton receiver API > - > > Key: PROTON-1952 > URL: https://issues.apache.org/jira/browse/PROTON-1952 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > > In the amqp standard, > [link-credit|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-flow-control] > is defined as: "the current maximum legal amount that the delivery-count can > be increased by". Only the receiver can set its value. > In the current proton API, we can only add to the link-credit. We cannot set > it (our need is to set it to a value less than the actual link-credit). > As to why we need this, we are trying to implement an asynchronous get with > timeout (by returning a std::future). > I understand that in the amqp standard, there are 2 supported modes of > delivery, and async get with timeout is not mentioned: > * [Synchronous get with > timeout|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp494704] > > * [Asynchronous > notifications|http://docs.oasis-open.org/amqp/core/v1.0/cos01/amqp-core-transport-v1.0-cos01.html#doc-idp502800] > Therefore, we're implementing it for its convenience to us (the client > receives the response/exception in his thread). > Problem arises when we start having timeouts. Briefly (I can give you more > details here if you want), having the ability to set the link-credit to a > lower value would facilitate our lives. -- 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-1952) Add possibility to set link-credit in proton receiver API
[ https://issues.apache.org/jira/browse/PROTON-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1952: --- Description: (was: We faced an issue with the idle timeout on linux. On windows, it seems to work. In our proton feature test suite, we test the idle timeout feature by doing a sleep in the method on_session_open. This should trigger a connection timeout. It works on windows, and it used to work with proton v0.16.0 on windows and linux. Removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)) > Add possibility to set link-credit in proton receiver API > - > > Key: PROTON-1952 > URL: https://issues.apache.org/jira/browse/PROTON-1952 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > -- 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-1952) Add possibility to set link-credit in proton receiver API
Jeremy created PROTON-1952: -- Summary: Add possibility to set link-credit in proton receiver API Key: PROTON-1952 URL: https://issues.apache.org/jira/browse/PROTON-1952 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.22.0 Reporter: Jeremy We faced an issue with the idle timeout on linux. On windows, it seems to work. In our proton feature test suite, we test the idle timeout feature by doing a sleep in the method on_session_open. This should trigger a connection timeout. It works on windows, and it used to work with proton v0.16.0 on windows and linux. Removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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] [Resolved] (DISPATCH-1130) Expose which message priority is being handled by an inter-router link
[ https://issues.apache.org/jira/browse/DISPATCH-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1130. Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 1.4.0 Link priority exposed. qdstat -l updated to show priority test added to ensure qdstat shows link priority > Expose which message priority is being handled by an inter-router link > -- > > Key: DISPATCH-1130 > URL: https://issues.apache.org/jira/browse/DISPATCH-1130 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.4.0 > > > There is now an inter-router link for each message priority. Which priority a > link is handling should be exposed in the management call to retrieve link > information. > Once that is done, qdstat -l should be changed to display the priority. > -- 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] (DISPATCH-1130) Expose which message priority is being handled by an inter-router link
[ https://issues.apache.org/jira/browse/DISPATCH-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646339#comment-16646339 ] ASF GitHub Bot commented on DISPATCH-1130: -- Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/389 > Expose which message priority is being handled by an inter-router link > -- > > Key: DISPATCH-1130 > URL: https://issues.apache.org/jira/browse/DISPATCH-1130 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Priority: Major > > There is now an inter-router link for each message priority. Which priority a > link is handling should be exposed in the management call to retrieve link > information. > Once that is done, qdstat -l should be changed to display the priority. > -- 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-dispatch pull request #389: DISPATCH-1130 Expose link priority
Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/389 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
