[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962964#comment-16962964 ] Alan Conway commented on PROTON-2105: - Nice one! I was expecting the go.mod to be in the go/ subdir of the repo, but on reflection & a bit of googling it's probably best in the repo root. You can theoretically have multiple modules in a repo, but since go mod uses git tag/branch names directly, you probably would get into trouble if you did - so having it in the repo root makes it clearer that it's a repo-wide thing. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > Fix For: proton-c-0.30.0 > > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2105) Support Go modules
[
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942919#comment-16942919
]
Alan Conway edited comment on PROTON-2105 at 10/2/19 4:05 PM:
--
Yep, I started looking at that before I was dragged off elsewhere. There's a
history of my blunders here:
# The directory layout is wrong: `go/src/qpid.apache.org/` is laid out
like a workspace, not a project. Classic newbie mistake by me long ago and
never corrected.
# The qpid.apache.org/... illusion is created by a "magic" go1 branch, and
some redirecting metadata tags on the qpid.apache.org website. The release
process to update the go1 branch is explained here:
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]
The magic go1 branch and HTTP redirect is nowadays deprecated in favour of
modules, we should get rid of it.
First re-organize the directory tree to be `proton/go/pkg/...` - as we're
changing package name we should take the chance to clean up.
Now go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including
Fedora 30)
The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.
I would do all of the above in a single release cycle and leave the
qpid.apache.org redirect stuck at the last release. That way existing users
won't be broken, new users use the new names.
It is possible we could make the qpid.apache.org/... names continue to work,
but I think it's better to make a clean break. The redirect-via-website is
bewildering compared to the straightforward "package-name-equals-git-repo"
convention which allows developers to easily find the source code, godocs etc.
was (Author: aconway):
Yep, I started looking at that before I was dragged off elsewhere. There's a
history of my blunders here:
# The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid
out like a workspace, not a project. Classic newbie mistake by me long ago and
never corrected.
# The qpid.apache.org/... illusion is created by a "magic" go1 branch, and
some redirecting metadata tags on the qpid.apache.org website. The release
process to update the go1 branch is explained here:
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]
The magic go1 branch and HTTP redirect is nowadays deprecated in favour of
modules, we should get rid of it. We have to change the package names, so we
want to get it right the first time :)
First re-organize the directory tree to be `proton/go/pkg/...` - as we're
changing package name we should take the chance to clean up.
Now go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including
Fedora 30)
The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.
I would do all of the above in a single release cycle and leave the
qpid.apache.org redirect stuck at the current release. That way existing users
won't be broken, new users use the new names.
It is possible we could make the qpid.apache.org/... names continue to work,
but I think it's better to make a clean break. The redirect-via-website is
bewildering compared to the straightforward "package-name-equals-git-repo"
convention which allows developers to easily find the source code, godocs etc.
> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage
> dependencies using go modules, dependencies must also be using go modules.
> Therefore, adding a go.mod file to each module would allow qpid proton go
> bindings to be managed as a go module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2105) Support Go modules
[
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942919#comment-16942919
]
Alan Conway edited comment on PROTON-2105 at 10/2/19 4:04 PM:
--
Yep, I started looking at that before I was dragged off elsewhere. There's a
history of my blunders here:
# The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid
out like a workspace, not a project. Classic newbie mistake by me long ago and
never corrected.
# The qpid.apache.org/... illusion is created by a "magic" go1 branch, and
some redirecting metadata tags on the qpid.apache.org website. The release
process to update the go1 branch is explained here:
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]
The magic go1 branch and HTTP redirect is nowadays deprecated in favour of
modules, we should get rid of it. We have to change the package names, so we
want to get it right the first time :)
First re-organize the directory tree to be `proton/go/pkg/...` - as we're
changing package name we should take the chance to clean up.
Now go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including
Fedora 30)
The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.
I would do all of the above in a single release cycle and leave the
qpid.apache.org redirect stuck at the current release. That way existing users
won't be broken, new users use the new names.
It is possible we could make the qpid.apache.org/... names continue to work,
but I think it's better to make a clean break. The redirect-via-website is
bewildering compared to the straightforward "package-name-equals-git-repo"
convention which allows developers to easily find the source code, godocs etc.
was (Author: aconway):
Yep, I started looking at that before I was dragged off elsewhere. There's a
history of my blunders here:
# The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid
out like a workspace, not a project. Classic newbie mistake by me long ago and
never corrected.
# The qpid.apache.org/... illusion is created by a "magic" go1 branch, and
some redirecting metadata tags on the qpid.apache.org website. The release
process to update the go1 branch is explained here:
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]
The magic go1 branch and HTTP redirect is nowadays deprecated in favour of
modules, we should get rid of it. We have to change the package names, so we
want to get it right the first time :)
Steps:
# Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll
have horrid long package names.
# Pick a hostname: github.com or gitbox.apache.org. It's a political decision
- github is more visible, but someone should check if apache policy requires
the word "apache" in the "official" package names. I'm staying out of it.
# Once the decision is made it's easy - assuming we choose github and
re-organize the directories as above it would be:
{code:java}
module github.com/qpid-proton/go/
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including
Fedora 30)
I would do all of the above in a single release cycle and leave the
qpid.apache.org redirect stuck at the current release. That way existing users
won't be broken, new users use the new names.
It is possible we could make the qpid.apache.org/... names continue to work,
but I think it's better to make a clean break. The redirect-via-website is
bewildering compared to the straightforward "package-name-equals-git-repo"
convention which allows developers to easily find the source code, godocs etc.
> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage
> dependencies using go modules, dependencies must also be using go modules.
> Therefore, adding a go.mod file to each module would allow qpid proton go
> bindings to be managed as a go module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2105) Support Go modules
[
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942919#comment-16942919
]
Alan Conway commented on PROTON-2105:
-
Yep, I started looking at that before I was dragged off elsewhere. There's a
history of my blunders here:
# The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid
out like a workspace, not a project. Classic newbie mistake by me long ago and
never corrected.
# The qpid.apache.org/... illusion is created by a "magic" go1 branch, and
some redirecting metadata tags on the qpid.apache.org website. The release
process to update the go1 branch is explained here:
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]
The magic go1 branch and HTTP redirect is nowadays deprecated in favour of
modules, we should get rid of it. We have to change the package names, so we
want to get it right the first time :)
Steps:
# Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll
have horrid long package names.
# Pick a hostname: github.com or gitbox.apache.org. It's a political decision
- github is more visible, but someone should check if apache policy requires
the word "apache" in the "official" package names. I'm staying out of it.
# Once the decision is made it's easy - assuming we choose github and
re-organize the directories as above it would be:
{code:java}
module github.com/qpid-proton/go/
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including
Fedora 30)
I would do all of the above in a single release cycle and leave the
qpid.apache.org redirect stuck at the current release. That way existing users
won't be broken, new users use the new names.
It is possible we could make the qpid.apache.org/... names continue to work,
but I think it's better to make a clean break. The redirect-via-website is
bewildering compared to the straightforward "package-name-equals-git-repo"
convention which allows developers to easily find the source code, godocs etc.
> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage
> dependencies using go modules, dependencies must also be using go modules.
> Therefore, adding a go.mod file to each module would allow qpid proton go
> bindings to be managed as a go module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1890) [c++] implement idle_timeout and heartbeats
[ https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened PROTON-1890: - > [c++] implement idle_timeout and heartbeats > --- > > Key: PROTON-1890 > URL: https://issues.apache.org/jira/browse/PROTON-1890 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-0.16.0 >Reporter: Praveen Bodke >Assignee: Alan Conway >Priority: Major > Attachments: PROTON-1890.zip, examples.diff > > > This is similar issue reported in PROTON-1782 for ruby. > We are facing this issue in cpp binding and i am able to reproduce the issue > with scheduled_send_03.cpp example. The test scenario is to drop all the > packets from both the interfaces after the successful connection. The only > change i made to this example is to send messages continuously inside the > send() method. The other end is detecting the error as it is sending the > empty frames and no response is heard. > The proton is not sending the heartbeat messages (empty frames) as the sender > is busy in sending the data frames. Is it not necessary to send empty frames > even if the data frames are sent? > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1890) [c++] implement idle_timeout and heartbeats
[ https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930711#comment-16930711 ] Alan Conway commented on PROTON-1890: - That does look like a bug. The client is sending the close frame and then waiting for the connection to close fully, but since we already know the connection is unresponsive (because we just timed out) the client should shut down both sides of the connection immediately and return PN_TRANSPORT_CLOSED. > [c++] implement idle_timeout and heartbeats > --- > > Key: PROTON-1890 > URL: https://issues.apache.org/jira/browse/PROTON-1890 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-0.16.0 >Reporter: Praveen Bodke >Assignee: Alan Conway >Priority: Major > Attachments: PROTON-1890.zip, examples.diff > > > This is similar issue reported in PROTON-1782 for ruby. > We are facing this issue in cpp binding and i am able to reproduce the issue > with scheduled_send_03.cpp example. The test scenario is to drop all the > packets from both the interfaces after the successful connection. The only > change i made to this example is to send messages continuously inside the > send() method. The other end is detecting the error as it is sending the > empty frames and no response is heard. > The proton is not sending the heartbeat messages (empty frames) as the sender > is busy in sending the data frames. Is it not necessary to send empty frames > even if the data frames are sent? > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1890) [c++] implement idle_timeout and heartbeats
[ https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928606#comment-16928606 ] Alan Conway commented on PROTON-1890: - [~bajanfella] the dispatcher is suppose to pick up the error from the TRANSPORT_CLOSED event, that's why it ignores the PN_TRANSPORT_ERROR event, as it repeats the same information available on the CLOSED. In your logs are you seeing a PN_TRANSPORT_CLOSED event? There should always be one, regardless how the transport terminates. If you can put together a small piece of code that reproduces the issue that would help greatly. > [c++] implement idle_timeout and heartbeats > --- > > Key: PROTON-1890 > URL: https://issues.apache.org/jira/browse/PROTON-1890 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-0.16.0 >Reporter: Praveen Bodke >Assignee: Alan Conway >Priority: Major > Attachments: PROTON-1890.zip, examples.diff > > > This is similar issue reported in PROTON-1782 for ruby. > We are facing this issue in cpp binding and i am able to reproduce the issue > with scheduled_send_03.cpp example. The test scenario is to drop all the > packets from both the interfaces after the successful connection. The only > change i made to this example is to send messages continuously inside the > send() method. The other end is detecting the error as it is sending the > empty frames and no response is heard. > The proton is not sending the heartbeat messages (empty frames) as the sender > is busy in sending the data frames. Is it not necessary to send empty frames > even if the data frames are sent? > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2100) Switch from CMake to Bazel?
[ https://issues.apache.org/jira/browse/PROTON-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924318#comment-16924318 ] Alan Conway commented on PROTON-2100: - I've hit bazel also in envoy. There are pros and cons, and I'm on record as hating Cmake (I never met a build system I didn't hate) but I think ultimately it would just be swapping one set of voodoo for another. CMake sucks but we've made it work. Bazel is better in some ways and sucks even worse in others. We could make it work, but after much painful and unproductive thrashing we'd just have Yet Another Over-Complex Build Framework that will be fashionable for a while, and then be sucky and out-dated compared to the next New Hotness. I don't see the gain. > Switch from CMake to Bazel? > --- > > Key: PROTON-2100 > URL: https://issues.apache.org/jira/browse/PROTON-2100 > Project: Qpid Proton > Issue Type: Wish > Components: proton-c >Reporter: Omer Katz >Priority: Major > > Bazel is a modern build system for polygot repositories like qpid-proton. > Using it should simplify how we build and package our bindings and c library. > This issue is an opportunity to discuss if we want to switch and if so, how. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2040) [cpp] Allow connection options to be updated for automatic reconnect.
[ https://issues.apache.org/jira/browse/PROTON-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-2040: --- Assignee: Andrew Stitcher (was: Alan Conway) > [cpp] Allow connection options to be updated for automatic reconnect. > - > > Key: PROTON-2040 > URL: https://issues.apache.org/jira/browse/PROTON-2040 > Project: Qpid Proton > Issue Type: New Feature > Components: cpp-binding >Reporter: Alan Conway >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.29.0 > > > Allow modification of connection options prior to an automatic re-connect. > Requested on mailing list: > > [https://lists.apache.org/thread.html/1fcd524de1e0d896a6f025470e0d774e051b8449dba0b9ddb3d0439e@%3Cusers.qpid.apache.org%3E] > > -- 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-2040) [cpp] Allow connection options to be updated for automatic reconnect.
Alan Conway created PROTON-2040: --- Summary: [cpp] Allow connection options to be updated for automatic reconnect. Key: PROTON-2040 URL: https://issues.apache.org/jira/browse/PROTON-2040 Project: Qpid Proton Issue Type: New Feature Components: cpp-binding Affects Versions: proton-c-0.27.1 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.28.0 Allow modification of connection options prior to an automatic re-connect. Requested on mailing list: [https://lists.apache.org/thread.html/1fcd524de1e0d896a6f025470e0d774e051b8449dba0b9ddb3d0439e@%3Cusers.qpid.apache.org%3E] -- 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-2035) Inability to mock Golang interfaces
[ https://issues.apache.org/jira/browse/PROTON-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-2035. - Resolution: Fixed Fix Version/s: proton-c-0.28.0 > Inability to mock Golang interfaces > --- > > Key: PROTON-2035 > URL: https://issues.apache.org/jira/browse/PROTON-2035 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.27.0 > Environment: Centos 7, Golang 1.11 >Reporter: Matt Threlfall >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.28.0 > > > I'll preface this by saying, I'm new to using Golang so this could entirely > be my misunderstanding. > I'm trying to use Proton-C 0.27's Golang bindings to connect to a broker and > receive messages from it which works fine. However I'm finding it hard to > mock the Receiver and Connection interfaces using either Go Mock or Testify's > mocks. Both complain that the mock interfaces can't be used as they don't > have an electron.closed function, despite it being defined. > I believe this to be due to the closed and waitSync functions being defined > in lowercase, changing them throughout the implementation to start with > capitals makes the mock interfaces work fine. I understand they're lowercase > however to keep them private to the package. > Is this an oversight in the implementation or is there a better way to mock > Connections and Receivers without editing the original source code? > Again I apologise if this is a simple matter, this is my first Golang project > and mock implementation. > > Thank you, > Matt -- 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-2035) Inability to mock Golang interfaces
[ https://issues.apache.org/jira/browse/PROTON-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16820528#comment-16820528 ] Alan Conway commented on PROTON-2035: - [~fletch] I think the fix above may solve your problem. Having private methods on a public interface was weird and un-necessary, moved them to a private interface. > Inability to mock Golang interfaces > --- > > Key: PROTON-2035 > URL: https://issues.apache.org/jira/browse/PROTON-2035 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.27.0 > Environment: Centos 7, Golang 1.11 >Reporter: Matt Threlfall >Assignee: Alan Conway >Priority: Minor > > I'll preface this by saying, I'm new to using Golang so this could entirely > be my misunderstanding. > I'm trying to use Proton-C 0.27's Golang bindings to connect to a broker and > receive messages from it which works fine. However I'm finding it hard to > mock the Receiver and Connection interfaces using either Go Mock or Testify's > mocks. Both complain that the mock interfaces can't be used as they don't > have an electron.closed function, despite it being defined. > I believe this to be due to the closed and waitSync functions being defined > in lowercase, changing them throughout the implementation to start with > capitals makes the mock interfaces work fine. I understand they're lowercase > however to keep them private to the package. > Is this an oversight in the implementation or is there a better way to mock > Connections and Receivers without editing the original source code? > Again I apologise if this is a simple matter, this is my first Golang project > and mock implementation. > > Thank you, > Matt -- 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-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800983#comment-16800983 ] Alan Conway commented on DISPATCH-1274: --- The issue this patch was aiming at is a set of often-called code points that *always* pass a literal 0 to schedule() just to put work on other threads. Those uses don't need a timed delay, just a thread-safe work queue. The overhead of clock_time() and a sorted schedule is always wasted for those calls. For code that actually is trying to set up a timed delay, I think the existing timers are fine - even if the delay sometimes happens to be 0. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800824#comment-16800824 ] Alan Conway commented on DISPATCH-1274: --- Another way to fix this would be to introduce an explicit "immediate" API rather than making it an optimization of timer_schedule(0). There are only a couple of places that make immediate calls an they are easy to separate from normal timer use. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800794#comment-16800794 ] Alan Conway commented on DISPATCH-1274: --- That part of the change (using an array instead of a linked list for timer lookup) can be backed out separately if desired. Otherwise the whole thing can be backed out for now since there isn't strong evidence that it provides a big speed up. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-2017) [go] fix proton-c version check
[ https://issues.apache.org/jira/browse/PROTON-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-2017. - Resolution: Fixed > [go] fix proton-c version check > --- > > Key: PROTON-2017 > URL: https://issues.apache.org/jira/browse/PROTON-2017 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.27.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > amqp/version.go checks for proton-c library version >= 0.10, it works with > all subsequent versions. > in the 0.27 release this was modified to 0.27 which breaks the go binding > with existing proton-c installations. > Fix on master and go1 release branch. -- 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-2017) [go] fix proton-c version check
Alan Conway created PROTON-2017: --- Summary: [go] fix proton-c version check Key: PROTON-2017 URL: https://issues.apache.org/jira/browse/PROTON-2017 Project: Qpid Proton Issue Type: Bug Affects Versions: proton-c-0.27.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.27.0 amqp/version.go checks for proton-c library version >= 0.10, it works with all subsequent versions. in the 0.27 release this was modified to 0.27 which breaks the go binding with existing proton-c installations. Fix on master and go1 release branch. -- 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-2016) [go] Fix incorrect version check in Go code.
Alan Conway created PROTON-2016: --- Summary: [go] Fix incorrect version check in Go code. Key: PROTON-2016 URL: https://issues.apache.org/jira/browse/PROTON-2016 Project: Qpid Proton Issue Type: Bug Reporter: Alan Conway The version check in amqp/version.go should check for proton >= 0.10, the Go binding does not depend on any proton-C core API's that have changed since then. The version was check was incorrectly updated to the current version 0.27, which breaks the go binding with older proton-C installations. Needs to be fixed on master and go1 branch. -- 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-2015) [cpp] listener::on_error() should throw by default
[ https://issues.apache.org/jira/browse/PROTON-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-2015. - Resolution: Fixed > [cpp] listener::on_error() should throw by default > -- > > Key: PROTON-2015 > URL: https://issues.apache.org/jira/browse/PROTON-2015 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.27.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.28.0 > > > messaging_handler::on_error() throws by default to ensure errors are not > silently ignored. > listener_handler::on_error() should do the same thing. > -- 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-2015) [cpp] listener::on_error() should throw by default
Alan Conway created PROTON-2015: --- Summary: [cpp] listener::on_error() should throw by default Key: PROTON-2015 URL: https://issues.apache.org/jira/browse/PROTON-2015 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.27.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.28.0 messaging_handler::on_error() throws by default to ensure errors are not silently ignored. listener_handler::on_error() should do the same thing. -- 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-1898) Memory leak related to sending
[ https://issues.apache.org/jira/browse/PROTON-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1898: --- Assignee: (was: Alan Conway) > Memory leak related to sending > -- > > Key: PROTON-1898 > URL: https://issues.apache.org/jira/browse/PROTON-1898 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.24.0 >Reporter: Christoph Scheiber >Priority: Major > > I started implementing a GO application using qpid electron. There is one > connection used to receive messages (at-least-once). It works nicely with low > memory consumption, multiple links and multiple go routines, 50 bytes > payload, up to 3000 msg/s > But as soon as the application starts sending messages (to reply over the > same connection) memory consumption is continuously growing up to 2GB where I > stopped. > Even if electron does not leave many options for wrong usage there might be > an issue in the application. > So I tried the qpid electron example > "https://github.com/apache/qpid-proton/blob/master/go/examples/electron/send.go";, > the same issue. > To reproduce it: > * use the sample program, I just added connection options for SASL PLAIN > * let it send 10 messages or more to one destination > My setup: > * windows 10 pro > * go1.10.2 windows/amd64 > * qpid 0.24.0-rc1 > * go files and lib build from same git repository clone and branch > * visual studio 2015, release build, no errors > * Broker: Solace VMR 8.11.0.1029 with different durable queues as source and > target > I tried also qpid proton 0.23.0 earlier, but saw the same problem. > I tried SendAsync and SendSync, both in 10-50 go routines in > parallel.Finally, with SendForget my worker routines were soon blocked and > did not come back. > Best regards > Christoph > -- 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-1871) Ruby leaks memory sending messages
[ https://issues.apache.org/jira/browse/PROTON-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1871: --- Assignee: (was: Alan Conway) > Ruby leaks memory sending messages > -- > > Key: PROTON-1871 > URL: https://issues.apache.org/jira/browse/PROTON-1871 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.23.0 >Reporter: roi costas >Priority: Major > Attachments: out_amq.rb, valgrind.txt > > > We have developed a simple fluentd output plugin which only sends messages to > AMQ. Sending messages with sender.send, memory increases continuously and it > is never released, not even when message processing is stopped. > The qpid-proton code is really simple and we have checked that it is > sender.send the one that leaks memory. > I have run memory_profiler, and the leak does not seem to by in ruby but in > C++ code because both the number of objects and bytes remain between constant > values. I have tried to debug it with valgrind but I cannot find the source > class of the leak. > I have attached the ruby code, ruby version 2.3.4. -- 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-447) Ruby types returned from Data should carry their AMQP type
[ https://issues.apache.org/jira/browse/PROTON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-447: -- Assignee: (was: Alan Conway) > Ruby types returned from Data should carry their AMQP type > -- > > Key: PROTON-447 > URL: https://issues.apache.org/jira/browse/PROTON-447 > Project: Qpid Proton > Issue Type: Improvement > Components: ruby-binding >Reporter: Darryl L. Pierce >Priority: Minor > > When a value is pulled out of a Qpid::Proton::Data type, such as a float or > integer, it should somehow carry with it its AMQP type. So, for example, if > the value returned is a ulong (represented as a Fixnum) then that should be > attached to the Fixnum so that it can potentially be put back into another > Data instance without losing that detail. -- 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-768) DECIMAL32 values are not consistent in Ruby
[ https://issues.apache.org/jira/browse/PROTON-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-768: -- Assignee: (was: Alan Conway) > DECIMAL32 values are not consistent in Ruby > --- > > Key: PROTON-768 > URL: https://issues.apache.org/jira/browse/PROTON-768 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Reporter: Darryl L. Pierce >Priority: Minor > Fix For: proton-c-future > > > On 32-bit EL6 running Ruby 1.8.7, DECIMAL32 values change. For example, the > following happened during running the rspec tests: > 2) A data object can hold a decimal32 >Failure/Error: expect(@data.decimal32).to eq(value) > > expected: 1161181977 > got: 1536795250 > > (compared using ==) ># ./spec/qpid/proton/data_spec.rb:304 -- 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] (PROTON-1643) [FreeBSD] ruby-old-example-test hangs
[
https://issues.apache.org/jira/browse/PROTON-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway closed PROTON-1643.
---
Resolution: Won't Fix
Those tests are outdated and have been removed.
> [FreeBSD] ruby-old-example-test hangs
> -
>
> Key: PROTON-1643
> URL: https://issues.apache.org/jira/browse/PROTON-1643
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>Priority: Major
> Labels: freebsd
>
> When running ctest ruby-example-test hangs.
> If you examine the process list there is a process {{/usr/local/bin/ruby23
> reactor/broker.rb -a :26780}} that has not exited. If you kill that process
> the test fails but the test run carries on.
--
This message was sent by Atlassian JIRA
(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] (DISPATCH-227) Independent filtering of logging to consoles and log files.
[ https://issues.apache.org/jira/browse/DISPATCH-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned DISPATCH-227: Assignee: (was: Alan Conway) > Independent filtering of logging to consoles and log files. > --- > > Key: DISPATCH-227 > URL: https://issues.apache.org/jira/browse/DISPATCH-227 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.5 >Reporter: Alan Conway >Priority: Minor > Fix For: Backlog > > > Currently the log filter settings are global, the same settings apply to > every log destination (files, consoles etc.) We need to be able to configure > different log filters on a per-console or per-file basis. We also need a new > log output type which sends log messges to an address that a console can > subscribe to. -- 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-1795) [cpp] imporved documentation for complex type mapping
[ https://issues.apache.org/jira/browse/PROTON-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1795: --- Assignee: (was: Alan Conway) > [cpp] imporved documentation for complex type mapping > - > > Key: PROTON-1795 > URL: https://issues.apache.org/jira/browse/PROTON-1795 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Priority: Major > > The complex type mapping section of the doc is brief and cryptic: > > [http://qpid.apache.org/releases/qpid-proton-0.21.0/proton/cpp/api/types_page.html] > > Needs review and improvement, including (but not limited to) > * explain why we allow conversion of AMQP maps to/from sequences: > order-preserving > * clarify use of #include files to enable all or selected conversions. > * include example code -- 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-1594) Expose remote host and port on transport
[ https://issues.apache.org/jira/browse/PROTON-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1594: --- Assignee: (was: Alan Conway) > Expose remote host and port on transport > > > Key: PROTON-1594 > URL: https://issues.apache.org/jira/browse/PROTON-1594 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Justin Ross >Priority: Major > Fix For: proton-c-future > > > So you can, for instance, log where you are connected to. -- 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] (PROTON-1688) [go] support encoding/decoding described arrays
[ https://issues.apache.org/jira/browse/PROTON-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1688. --- Resolution: Fixed Will be implemented as part of PROTON-2008 > [go] support encoding/decoding described arrays > --- > > Key: PROTON-1688 > URL: https://issues.apache.org/jira/browse/PROTON-1688 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-future > > > Add support for AMQP described arrays. > Most described types are already covered by amqp.Described, but arrays are a > special case. > An array of described values has the descriptor and type encoded only once, > followed by the undecorated values. Proton-C has a special API for this, it > is not the same as starting an array and then encoding each value with the > description. -- 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-1765) [ruby] auto-test of installed gem
[
https://issues.apache.org/jira/browse/PROTON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1765:
---
Assignee: (was: Alan Conway)
> [ruby] auto-test of installed gem
> -
>
> Key: PROTON-1765
> URL: https://issues.apache.org/jira/browse/PROTON-1765
> Project: Qpid Proton
> Issue Type: Improvement
>Reporter: Alan Conway
>Priority: Trivial
>
> Restore the following tests to the ruby/CMakeLists.txt section that builds a
> gem:
> {code:java}
> # Test installing the gem.
> to_native_path("${bin}/install" gem_home)
> set(gem_env ${env_py} -- "GEM_HOME=${gem_home}"
> "LD_LIBRARY_PATH=${c_lib_dir}")
> add_test(
> NAME ruby-gem-install
> COMMAND ${gem_env} ${GEM_EXE} install "${GEM_FILE}" --
> "--with-qpid-proton-include=${CMAKE_SOURCE_DIR}/proton-c/include"
> "--with-qpid-proton-lib=${c_lib_dir}"
> )
> # Test running examples against the installed gem
> add_test(
> NAME ruby-gem-examples
> COMMAND ${gem_env} ${RUBY_EXECUTABLE} example_test.rb -v
> WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/examples/ruby
> )
> SET_TESTS_PROPERTIES(ruby-gem-examples PROPERTIES DEPENDS ruby-gem-install) #
> Run after install{code}
> This works on some platforms (fedora 26) but fails on Travis CI builds in
> the ruby-gem-examples test, e.g.
> [https://travis-ci.org/alanconway/qpid-proton/jobs/342502018]
> Doesn't seem to indicate a problem with the Gem, but rather with the test
> setup. The error is like this:
> {code:java}
> 2: Test command: /opt/pyenv/shims/python
> "/home/travis/build/alanconway/qpid-proton/proton-c/env.py" "--"
> "GEM_HOME=/home/travis/build/alanconway/qpid-proton/build/proton-c/bindings/ruby/install"
> "LD_LIBRARY_PATH=/home/travis/build/alanconway/qpid-proton/build/proton-c"
> "/home/travis/.rvm/rubies/ruby-2.4.1/bin/ruby" "example_test.rb" "-v"
> 2: Test timeout computed to be: 1500
> 2:
> /home/travis/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in
> `require': incompatible library version -
> /home/travis/build/alanconway/qpid-proton/build/proton-c/bindings/ruby/install/gems/qpid_proton-0.21.0/lib/cproton.so
> (LoadError)
> 2:from
> /home/travis/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in
> `require'
> 2:from
> /home/travis/build/alanconway/qpid-proton/build/proton-c/bindings/ruby/install/gems/qpid_proton-0.21.0/lib/qpid_proton.rb:19:in
> `'
> 2:from
> /home/travis/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in
> `require'
> 2:from
> /home/travis/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in
> `rescue in require'
> 2:from
> /home/travis/.rvm/rubies/ruby-2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in
> `require'
> 2:from example_test.rb:22:in `'
> 2/32 Test #2: ruby-gem-examples ***Failed0.15 sec{code}
--
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-1988) [cpp] streamable message support
[ https://issues.apache.org/jira/browse/PROTON-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1988: --- Assignee: (was: Alan Conway) > [cpp] streamable message support > > > Key: PROTON-1988 > URL: https://issues.apache.org/jira/browse/PROTON-1988 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Priority: Major > > C++ API support for streaming large messages in chunks (too large to fit > entire message in memory) > The C link-level API does support streaming messages in chunks, but the C > message encoder/decoder and the proton::message type do. Provide an > alternative (or extended) C++ message type with a byte-stream API to > send/receive the body data in chunks, without every requiring the entire body > to be held in memory. > Use cases: > # Only the message body need be streamed. Properties are encoded/decode as a > unit before sending/receiving any of the body. Most client/endpoint > applications would work this way. > # The entire message, headers, properties and all, need to be streamed, with > support for partial decoding of an incoming message and efficient pass thru > (incoming to outgoing without decode/re-encode). Only advanced intermediaries > are likely to need this (e.g. this is what dispatch router does.) > > > -- 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-855) Add axTLS (embedded SSL) support to proton-c
[ https://issues.apache.org/jira/browse/PROTON-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-855: -- Assignee: (was: Alan Conway) > Add axTLS (embedded SSL) support to proton-c > > > Key: PROTON-855 > URL: https://issues.apache.org/jira/browse/PROTON-855 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: proton-0.9, proton-0.9.1, proton-0.10 > Environment: Platform independent >Reporter: Tomasz Nowicki >Priority: Major > Labels: features, patch > Fix For: proton-c-future > > Attachments: axtls.c, axtls_proton_example.c, qpidproton-AXTLS.patch, > ssl_io.h > > Original Estimate: 0h > Remaining Estimate: 0h > > The axTLS embedded SSL project is a highly configurable client/server > TLSv1 SSL library designed for platforms with small memory requirements. > It comes with a small HTTP/HTTPS server and additional test tools. > axTLS It's free! (BSD style licensing) > http://axtls.sourceforge.net/ > axTLS integration with proton is done on socket layer(posix layer). On the > other hand OpenSSL integration with proton is done on the transport layer. To > use both solutions we had to add two methods pn_ssl_recv i pn_ssl_send > (daclared in include/ssl_io.h) which in openssl mode, without crypting, > invoke native proton "pn_send" and "pn_receive (io.c)". In axTLS mode, those > methods are replaced with proper axtls comunication methods. Those are > defined in openssl.c, ssl_stub.c, axtls.c and located in src/ssl. > Methods pn_ssl_recv and pn_ssl_send replace original pn_send and pn_recv used > in pni_connection_writable(pn_selectable_t *sel), > pni_connection_readable(pn_selectable_t *sel) (connection.c). > Moreover we introduced new file axtls.c located in src/ssl. The file is an > equivalent of openssl.c, implementing base ssl methods: PN_EXTERN > pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t mode); > PN_EXTERN void pn_ssl_domain_free( pn_ssl_domain_t *domain ); etc > Example of axTLS integration with ex ActiveMQ > atatched(axtls_proton_example.c): > It's based on > http://mail-archives.us.apache.org/mod_mbox/qpid-proton/201501.mbox/%3ccacl1bnc5jerbnikd_4fgkjqh13h5nl_2z-sszp3jg2t+ywa...@mail.gmail.com%3E -- 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-1837) [c] client generates invalid attach/detach sequence
[
https://issues.apache.org/jira/browse/PROTON-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1837:
---
Assignee: (was: Alan Conway)
> [c] client generates invalid attach/detach sequence
> ---
>
> Key: PROTON-1837
> URL: https://issues.apache.org/jira/browse/PROTON-1837
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Priority: Minor
>
> There is a disabled test to reproduce this problem, see
> test_duplicate_link_client() in
> [https://github.com/alanconway/qpid-proton/blob/master/c/tests/connection_driver.c#L498]
> pni_process does all pending link opens before all pending link closes, it
> does not respect the order of individual open/close calls in the code. This
> doesn't cause a problem for distinct links but if a link of the same name is
> opened/closed/reopened very quickly it can cause a problem:
> For example if l1 and l2 are both pn_links with name "x" then this sequence:
> {code:java}
> open(l1); close(l1); open(l2){code}
> generates this illegal protocol sequence:
> {code:java}
> attach("x"); attach("x"); detach(0) // 0 is the handle assigned to "x"{code}
> instead of the intended legal sequence:
> {code:java}
> attach("x"); detach(0); attach("x") // detach(0) detaches the first "x" so
> second "x" is allowed{code}
> NOTE: This applies to all endpoints, not just links but since connections and
> sessions don't have client-assignable names that can clash, the problem only
> shows up for links and only if the detach/attach for the same name is
> processed in the same transport batch. This is unlikely in practice and was
> discovered only because of investigation of PROTON-1832.
--
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] (DISPATCH-1258) Crash executing http test
[
https://issues.apache.org/jira/browse/DISPATCH-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned DISPATCH-1258:
-
Assignee: (was: Alan Conway)
> Crash executing http test
> -
>
> Key: DISPATCH-1258
> URL: https://issues.apache.org/jira/browse/DISPATCH-1258
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.5.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1258-ctest.txt
>
>
> Ctest fails with a router core. Text of ctest run posted separately.
> h3. Ctest command line
> ctest -VV -R system_tests_http
> h3. LibWebSockets version info
> libwebsockets-3.0.1-2.fc29.x86_64
> libwebsockets-devel-3.0.1-2.fc29.x86_64
> libwebsockets-debuginfo-3.0.1-2.fc29.x86_64
> libwebp-1.0.0-2.fc29.x86_64
> libwebsockets-debugsource-3.0.1-2.fc29.x86_64
> h3. GDB Backtrace
> {{gdb) bt}}
> {{#0 SSL_get0_alpn_selected (ssl=0x0, data=data@entry=0x7f064f343f20,
> len=len@entry=0x7f064f343f1c) at ssl/ssl_lib.c:2802}}
> {{#1 0x7f065dca5f3c in lws_tls_server_conn_alpn
> (wsi=wsi@entry=0x7f0640245ad0)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/tls/tls-server.c:76}}
> {{#2 0x7f065dca63b5 in lws_server_socket_service_ssl
> (wsi=wsi@entry=0x7f0640245ad0, accept_fd=accept_fd@entry=15)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/tls/tls-server.c:368}}
> {{#3 0x7f065dcaa21e in lws_adopt_descriptor_vhost (vh=,
> type=, fd=fd@entry=..., }}
> {{ vh_prot_name=vh_prot_name@entry=0x0, parent=parent@entry=0x0)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/roles/http/server/server.c:2036}}
> {{#4 0x7f065dca4547 in rops_handle_POLLIN_listen (pt=0x23f7830,
> wsi=0x7f0640086660, pollfd=0x23f9528)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/roles/listen/ops-listen.c:126}}
> {{#5 0x7f065dc9739b in lws_service_fd_tsi
> (context=context@entry=0x23f7790, pollfd=0x23f9528, tsi=tsi@entry=0)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/core/service.c:891}}
> {{#6 0x7f065dca81b0 in _lws_plat_service_tsi (context=0x23f7790,
> timeout_ms=, tsi=0)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/plat/lws-plat-unix.c:300}}
> {{#7 0x7f065dc97485 in lws_service (context=0x23f7790,
> timeout_ms=)}}
> {{ at
> /usr/src/debug/libwebsockets-3.0.1-2.fc29.x86_64/lib/core/service.c:958}}
> {{#8 0x7f065e1785dc in http_thread_run (v=0x241b9e0) at
> /home/chug/git/qpid-dispatch/src/http-libwebsockets.c:481}}
> {{#9 0x7f065e05058e in start_thread (arg=) at
> pthread_create.c:486}}
> {{#10 0x7f065dbbe6a3 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
> {{(gdb) }}{{}}{{}}
>
--
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-1593) Add timestamps to trace output
[ https://issues.apache.org/jira/browse/PROTON-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1593: --- Assignee: (was: Alan Conway) > Add timestamps to trace output > -- > > Key: PROTON-1593 > URL: https://issues.apache.org/jira/browse/PROTON-1593 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Justin Ross >Priority: Major > Labels: logging > Fix For: proton-c-future > > > The timestamps need not be wall clock time. -- 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-1883) add interop smoke test for examples
[ https://issues.apache.org/jira/browse/PROTON-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1883: --- Assignee: (was: Alan Conway) > add interop smoke test for examples > --- > > Key: PROTON-1883 > URL: https://issues.apache.org/jira/browse/PROTON-1883 > Project: Qpid Proton > Issue Type: Bug > Components: examples >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Priority: Major > > Add a simple interop smoke-test for the examples: run simple_send and > simple_receive against example brokers to verify that each language pair can > interoperate. -- 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-1840) [cpp] Nested complex types fail compilation with "incomplete type" error
[
https://issues.apache.org/jira/browse/PROTON-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1840:
---
Assignee: (was: Alan Conway)
> [cpp] Nested complex types fail compilation with "incomplete type" error
>
>
> Key: PROTON-1840
> URL: https://issues.apache.org/jira/browse/PROTON-1840
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
> Labels: codec
>
> When using nested complex types (for example, a list of maps or an array of
> lists), the compiler fails to compile. For example, the following code
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include
> #include
> #include
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"},
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false,
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&,
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename
> proton::value::assignable::type
> proton::value::operator=(const T&) [with T =
> std::vector >; typename
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from
> ‘proton::value::value(const T&, typename proton::value::assignable::type*)
> [with T = std::vector >; typename
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type
> ‘proton::internal::type_id_of >’ used
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {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] [Assigned] (PROTON-1987) [cpp] Encode/decode all legal message body types.
[ https://issues.apache.org/jira/browse/PROTON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1987: --- Assignee: (was: Alan Conway) > [cpp] Encode/decode all legal message body types. > - > > Key: PROTON-1987 > URL: https://issues.apache.org/jira/browse/PROTON-1987 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Priority: Major > > From AMQP spec > [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format] > _The body consists of one of the following three choices:_ > # _one or more > [data|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-data] > sections,_ > # _one or more > [amqp-sequence|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-sequence] > sections,_ > # _or a single > [amqp-value|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-value] > section._ > It actually *is* currently possible to encode and decode all these body > formats using a combination of AMQP value types and the message::inferred() > flag. However, they way it works is not intuitive, and it is easy to encode > an illegal body format (e.g. mix section types) which won't be detected till > runtime. > A better API should: > * Make it easy to set/determine the body encoding style. > * Type safe API that can only encode legal body formats. > -- 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-1665) Review locking - TLS / SSL thread safety with proactor
[ https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1665: --- Assignee: (was: Alan Conway) > Review locking - TLS / SSL thread safety with proactor > -- > > Key: PROTON-1665 > URL: https://issues.apache.org/jira/browse/PROTON-1665 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Alan Conway >Priority: Major > Labels: tls > Fix For: proton-c-future > > > ssl_domain objects are semi-global. > For example two connections simultaneously creating or releasing their own > private pn_ssl_t objects may mess up the refcount of the shared > pn_ssl_domain_t object leading to memory corruption or leaks. > Windows schannel is further complicated by the OS internal refcounting of its > security context thingies. That may get automatically solved by the above, > or may require a separate JIRA to track. The same may apply to openssl. > The obvious thread-safety issues were addressed by PROTON-1620 and the use > of per-transport SSL objects appears to be correct and safe. However we need > a careful review of the use of shared OpenSSL objects (related to SSL domains > and certificate stores) to ensure they are being used safely and no > additional locks are needed. -- 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-778) [c] Optimize de-duplication of PN_LINK_FLOW events
[ https://issues.apache.org/jira/browse/PROTON-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-778: -- Assignee: (was: Alan Conway) > [c] Optimize de-duplication of PN_LINK_FLOW events > -- > > Key: PROTON-778 > URL: https://issues.apache.org/jira/browse/PROTON-778 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-0.8 >Reporter: Ken Giusti >Priority: Major > Labels: perf > > As per Rafi's suggestion on the proton mailing list: > http://mail-archives.apache.org/mod_mbox/qpid-proton/201412.mbox/%3CCACL1BnB5s6hTVA7KpjHKE02d1sLZb=PZPOQqpjUUeeaVk=g...@mail.gmail.com%3E > To summarize: emit the PN_LINK_FLOW event for local credit change only once > after all pending messages for a given link have been written to the > transport. -- 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-1615) c++: container leaks if exception thrown by handler.
[
https://issues.apache.org/jira/browse/PROTON-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1615:
---
Assignee: (was: Alan Conway)
> c++: container leaks if exception thrown by handler.
>
>
> Key: PROTON-1615
> URL: https://issues.apache.org/jira/browse/PROTON-1615
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Reporter: Alan Conway
>Priority: Major
> Labels: leak
>
> An exception throw by a handler is re-thrown out of container.run() as
> expected, however
> the container does not shut down cleanly and many leaks are reported by
> valgrind or asan. The container should be exception-safe.
> To demonstrate the problem apply this small patch to the helloworld_direct
> example.
> examples/cpp/helloworld_direct.cpp | 1 +
> modified examples/cpp/helloworld_direct.cpp
> @@ -53,6 +53,7 @@ class hello_world_direct : public proton::messaging_handler
> {
>
> // Receive one message and stop listener
> void on_message(proton::delivery &, proton::message &m) OVERRIDE {
> +throw std::runtime_error("thrown from on_message");
> std::cout << m.body() << std::endl;
> listener.stop();
> }
--
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] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests
[
https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned DISPATCH-244:
Assignee: (was: Alan Conway)
> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Priority: Major
> Fix For: Backlog
>
> Attachments: A-perf-flamegraph-3075-work.svg,
> dispatch-244-gdb-backtrace.txt
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when
> connected to a VPN.
> - about 10x slower on VPN configured to use TCP connection
> - about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface.
> `wallace` below is the local host name, but is not mentioned in any tests so
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1 LDAP242
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72
> Standard query 0xd03f A wallace.lab.bos.redhat.com
> {code}
--
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-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1964:
---
Assignee: (was: Alan Conway)
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> To reproduce the problem see the comments in c/tests/pn_test_proactor.cpp in
> function proactor::wait_next().
> The fix to PROTON-1586 was to have the connection_driver batch to hide events
> after TRANSPORT_CLOSE by returning NULL as if the batch were empty. However,
> that is too late to prevent the batch being returned by the proactor - from
> the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> This is really a bug in the pn_connection_driver, not the proactor, and it
> should be fixed there so that all proactors and non-proactor applications
> will benefit.
>
> Original reproducer:
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy/opensource/qpid-proton/build
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$ examples/c/send nosuchhost
> PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
> to nosuchhost:5672
> epoll proactor failure in
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648:
> "arming polled file descriptor": No such file or directory
> Aborted (core dumped)
> [gmurthy@localhost build]$
> {noformat}
> The proactor code coredumps.
--
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-1637) C++ binding relies on private symbols from proton-core library
[
https://issues.apache.org/jira/browse/PROTON-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1637:
---
Assignee: Andrew Stitcher (was: Alan Conway)
> C++ binding relies on private symbols from proton-core library
> --
>
> Key: PROTON-1637
> URL: https://issues.apache.org/jira/browse/PROTON-1637
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>
> The C++ binding relies on some "internal" symbols or the proton-core library
> Notably {{pni_message_with_extra()}} &{{pni_message_get_extra()}}. But also
> {{pni_log_enabled()}} etc. too
> The proton-core library is supposed to export everything needed by bindings
> publically so that there is no "under-the-covers" private agreement between
> them.
> There isn't really any other way to allow bindings to be generally written.
--
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] (PROTON-1577) c++ add uncounted wrapper for pn_xxx types
[ https://issues.apache.org/jira/browse/PROTON-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1577. --- Resolution: Won't Fix > c++ add uncounted wrapper for pn_xxx types > -- > > Key: PROTON-1577 > URL: https://issues.apache.org/jira/browse/PROTON-1577 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > Proton refcounting is not thread safe, so it is important internally to avoid > accidental decref at an unsafe moment by the wrapper destructors. Provide an > uncounted wrapper template for internal use only, provides the same > functions as the normal wrapper class but with no automatic refcounting -- 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-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*
[ https://issues.apache.org/jira/browse/PROTON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-448. Resolution: Fixed > Ruby bindings need to have their set calls updated to properly map values to > pn_data_t* > --- > > Key: PROTON-448 > URL: https://issues.apache.org/jira/browse/PROTON-448 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-0.5 >Reporter: Darryl L. Pierce >Assignee: Alan Conway >Priority: Major > > When using the APIs in Qpid::Proton::Data I'm seeing: > irb(main):001:0> require 'qpid_proton' > => true > irb(main):002:0> data = Qpid::Proton::Data.new > => # > irb(main):003:0> data.ubyte = 3 > value=3 > TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16 > in SWIG method 'pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `ubyte=' > from (irb):3 > from /usr/bin/irb:12:in `' -- 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-638) links never shrink the number of pooled delivery objects
[ https://issues.apache.org/jira/browse/PROTON-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-638: -- Assignee: (was: Alan Conway) > links never shrink the number of pooled delivery objects > > > Key: PROTON-638 > URL: https://issues.apache.org/jira/browse/PROTON-638 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Rafael H. Schloming >Priority: Major > Labels: perf > Fix For: proton-c-future > > -- 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-6676) QPID 0.32 throughput drop sharply with HA module
[ https://issues.apache.org/jira/browse/QPID-6676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned QPID-6676: - Assignee: (was: Alan Conway) > QPID 0.32 throughput drop sharply with HA module > > > Key: QPID-6676 > URL: https://issues.apache.org/jira/browse/QPID-6676 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.32, qpid-cpp-0.34 > Environment: CentOS6.5 X86_64 >Reporter: Robert Lee >Priority: Critical > > I build QPID 0.32 C++ broker with HA module on CentOS6.5 and run a cluster of > 2 nodes with --ha-replicate=all, Then send messages using QPID Messaging API > continuously with protocol AMQP0-10 and I meet a strange problem,If I purge > all of messages in a queue and continue to send messages,The throughput drop > sharply. And the same problem seen on QPID 0.34 > Steps to reproduce: > 1: > qpid-config add exchange direct testHA.exchange > qpid-config add queue testHA.queue --max-queue-size 1048576000 > qpid-config bind testHA.exchange testHA.queue testHA.binding > 2: > Run "qpid-queue-stats -f testHA.queue" on a console > 3: > Send 10 messages to testHA.exchange with routingkey testHA.binding > 4: > Purge queue use the QPID manager tool (qpid-tool) > 5: > Repeat step 3 > In the step 3, I can send about 8000 messages per second one producer, and In > step 4, I purge all messages in the queue, then send messages continue, I can > only send about 300 messages per second, But when I shutdown the backup node > the throughput back to normal -- 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-1496) C epoll proactor needs better timer implementation for connections
[ https://issues.apache.org/jira/browse/PROTON-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1496: --- Assignee: Cliff Jansen (was: Alan Conway) > C epoll proactor needs better timer implementation for connections > -- > > Key: PROTON-1496 > URL: https://issues.apache.org/jira/browse/PROTON-1496 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: Linux environments with epoll support >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > The epoll proactor allocates a timerfd per connection. This is a convenience > for the initial implementation and may surprise some applications running > into system limits on file descriptors twice as fast as expected. > The timer is used for heartbeats. It should be possible to write a > per-proactor heartbeat timer that is shared among the connections -- 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-584) Proton-c transport reserves large buffers for brief use
[ https://issues.apache.org/jira/browse/PROTON-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-584: -- Assignee: Andrew Stitcher (was: Alan Conway) > Proton-c transport reserves large buffers for brief use > --- > > Key: PROTON-584 > URL: https://issues.apache.org/jira/browse/PROTON-584 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-0.8 >Reporter: Cliff Jansen >Assignee: Andrew Stitcher >Priority: Major > Labels: perf > Fix For: proton-c-future > > > When processing transfer frames for incoming messages, Proton requires a > temporary buffer holding the whole transfer frame briefly in contiguous space > in the transport before moving it to the engine proper which holds the > content in a separate memory area. > pn_transport_capacity grows the buffer in the non-ssl case > (transport->input_buf), and openssl.c largely duplicates the code (including > the comment about "no limit") for ssl->inbuf for ssl connections. > Either way, a large message will trigger reserving a similarly large buffer > for the rest of the life of the connection. > Is it necessary for the transport to buffer the whole message body and hang > on to that memory? -- 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-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved DISPATCH-1274. --- Resolution: Fixed Fix Version/s: 1.6.0 > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782023#comment-16782023 ] Alan Conway commented on DISPATCH-1274: --- Proposed fix on [https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;a=shortlog;h=refs/heads/schedule-zero] I'm not seeing any impressive changes from this fix, so I'm leaving it on a branch for further evaluation for now. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-1274) Optimize qd_timer_schedule(0)
Alan Conway created DISPATCH-1274: - Summary: Optimize qd_timer_schedule(0) Key: DISPATCH-1274 URL: https://issues.apache.org/jira/browse/DISPATCH-1274 Project: Qpid Dispatch Issue Type: Improvement Components: Container Affects Versions: 1.5.0 Reporter: Alan Conway Assignee: Alan Conway qd_timer_schedule() uses the general timeout mechanisms which includes checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and adding/removing work items from sorted list. Optimize the schedule(0) case as a simple work_list using pn_proactor_interrupt() for wakeups. -- 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-2008) [go] native implementation of go client.
Alan Conway created PROTON-2008: --- Summary: [go] native implementation of go client. Key: PROTON-2008 URL: https://issues.apache.org/jira/browse/PROTON-2008 Project: Qpid Proton Issue Type: Improvement Components: go-binding Affects Versions: proton-c-0.26.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.27.0 Write a pure-Go implementation of the Go client. Standard tools for distributing and installing Go packages do not handle C dependencies. This makes the Go client hard to adopt in an all-Go development environment. Frequent calls to a C library can also create performance issues, as the Go scheduler has to take special steps to execute C functions which require a larger stack than native go functions. Port the relevant parts of the proton-C library (the codec and protocol engine) to Go. -- 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-8134) qpid::client::Message::send multiple memory leaks
[ https://issues.apache.org/jira/browse/QPID-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned QPID-8134: - Assignee: (was: Alan Conway) > qpid::client::Message::send multiple memory leaks > - > > Key: QPID-8134 > URL: https://issues.apache.org/jira/browse/QPID-8134 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-1.37.0, qpid-cpp-1.38.0 > Environment: *CentOS* Linux release 7.4.1708 (Core) > Linux localhost.novalocal 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-dispatch-debuginfo-1.0.0-1.el7.x86_64 > python-*qpid*-1.37.0-1.el7.noarch > *qpid*-proton-c-0.18.1-1.el7.x86_64 > python-*qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-proton-debuginfo-0.18.1-1.el7.x86_64 > *qpid*-cpp-debuginfo-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-devel-1.37.0-1.el7.x86_64 > *qpid*-cpp-server-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-1.37.0-1.el7.x86_64 > >Reporter: dan clark >Priority: Major > Labels: leak, maven > Attachments: drain.cpp, godrain.sh, gospout.sh, qpid-8134.tgz, > qpid-stat.out, spout.cpp, spout.log > > Original Estimate: 40h > Remaining Estimate: 40h > > There may be multiple leaks of the outgoing message structure and associated > fields when using the qpid::client::amqp0_10::SenderImpl::send function to > publish messages under certain setups. I will concede that there may be > options that are beyond my ken to ameliorate the leak of messages structures, > especially since there is an indication that under prolonged runs (a > demonized version of an application like spout) that the statistics for quidd > indicate increased acquires with zero releases. > The basic notion is illustrated with the test application spout (and drain). > Consider a long running daemon reducing the overhead of open/send/close by > keeping the message connection open for long periods of time. Then the logic > would be: start application/open connection. In a loop send data (and never > reach a close). Thus the drain application illustrates the behavior and > demonstrates the leak using valgrind by sending the data followed by an > exit(0). > Note also the lack of 'releases' associated with the 'acquires' in the stats > output. > Capturing the leaks using the test applications spout/drain required adding > an 'exit()' prior to the close, as during normal operations of a daemon, the > connection remains open for a sustained period of time, thus the leak of > structures within the c++ client library are found as structures still > tracked by the library and cleaned up on 'connection.close()', but they > should be cleaned up as a result of the completion of the send/receive ack or > the termination of the life of the message based on the TTL of the message, > which ever comes first. I have witnessed growth of the leaked structures > into the millions of messages lasting more than 24hours with short (300sec) > TTL of the messages based on scenarios attached using spout/drain as test > vehicle. > The attached spout.log uses a short 10message test and the spout.log contains > 5 sets of different structures leaked (found with the 'bytes in 10 blocks are > still reachable' lines, that are in line with much more sustained leaks when > running the application for multiple days with millions of messages. > The leaks seem to be associated with structures allocation 'stdstrings' to > save the "subject" and the "payload" for string based messages using send for > amq.topic output. > Suggested work arounds are welcome based on application level changes to > spout/drain (if they are missing key components) or changes to the > address/setup of the queues for amq.topic messages (see the 'gospout.sh and > godrain.sh' test drivers providing the specific address structures being used. > For example, the following is one of the 5 different categories of leaked > data from 'spout.log' on a valgrind analysis of the output post the send and > session.sync but prior connection.close(): > > ==3388== 3,680 bytes in 10 blocks are still reachable in loss record 233 of > 234 > ==3388== at 0x4C2A203: operator new(unsigned long) > (vg_replace_malloc.c:334) > ==3388== by 0x4EB046C: qpid::client::Message::Message(std::string const&, > std::string const&) (Message.cpp:31) > ==3388== by 0x51742C1: > qpid::client::amqp0_10::OutgoingMessage::OutgoingMessage() > (OutgoingMessage.cpp:167) > ==3388== by 0x5186200: > qpid::client::amqp0_10::SenderImpl::sendImpl(qpid::messaging::Message const&) > (SenderImpl.cpp:140) > ==3388== by 0x5186485: operator() (SenderImpl.h:114) > ==3388== by 0x5186485: execute > (SessionImpl.h:102) > ==33
[jira] [Commented] (PROTON-1996) Proton Client is "stalled" during SASL handshake
[
https://issues.apache.org/jira/browse/PROTON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756258#comment-16756258
]
Alan Conway commented on PROTON-1996:
-
Not sure if this is relevant but when I was interop testing proton example
brokers and clients I saw a similar stall if SASL was completely disabled on
one side of the connection. I'm not sure if/how that can happen with dispatch,
I think it's always got SASL enabled.
To get detailed logs from dispatch, put this in your config (it includes the
equivalent of the PN_TRACE_FRM=1 logs)
log {
module: DEFAULT
enable: trace+
}
> Proton Client is "stalled" during SASL handshake
>
>
> Key: PROTON-1996
> URL: https://issues.apache.org/jira/browse/PROTON-1996
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.25.0, proton-j-0.31.0
>Reporter: Daniel Maier
>Priority: Major
>
> Hi,
> When I try to connect with proton vertx client to an AMQP server, the client
> seems to come sporadically in some kind of "stalled" state. The logs, see
> below, look like the server just not responds anymore which cause the client
> to be stalled. There are no more logs regarding SASL handshake.
> Used server is qdrouter.
> Would it make sense from your point of view to introduce a timeout here? Or
> is the responsibility for this in the calling application?
> {code}
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> io.netty.handler.ssl.SslHandler - [id: 0x429f2c43, L:/100.100.0.6:45982 -
> R:xxx.com/xxx:443] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
> state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
> 08:32:49.418 [vert.x-eventloop-thread-0] TRACE
> io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> {code}
> Thanks
> Daniel
--
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] [Comment Edited] (PROTON-1996) Proton Client is "stalled" during SASL handshake
[
https://issues.apache.org/jira/browse/PROTON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756258#comment-16756258
]
Alan Conway edited comment on PROTON-1996 at 1/30/19 4:01 PM:
--
Not sure if this is relevant but when I was interop testing proton example
brokers and clients I saw a similar stall if SASL was completely disabled on
one side of the connection. I'm not sure if/how that can happen with dispatch,
I think it's always got SASL enabled.
To get detailed logs from dispatch, put this in your config (it includes the
equivalent of the PN_TRACE_FRM=1 logs)
{code:java}
log {
module: DEFAULT
enable: trace+
}
{code}
was (Author: aconway):
Not sure if this is relevant but when I was interop testing proton example
brokers and clients I saw a similar stall if SASL was completely disabled on
one side of the connection. I'm not sure if/how that can happen with dispatch,
I think it's always got SASL enabled.
To get detailed logs from dispatch, put this in your config (it includes the
equivalent of the PN_TRACE_FRM=1 logs)
log {
module: DEFAULT
enable: trace+
}
> Proton Client is "stalled" during SASL handshake
>
>
> Key: PROTON-1996
> URL: https://issues.apache.org/jira/browse/PROTON-1996
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.25.0, proton-j-0.31.0
>Reporter: Daniel Maier
>Priority: Major
>
> Hi,
> When I try to connect with proton vertx client to an AMQP server, the client
> seems to come sporadically in some kind of "stalled" state. The logs, see
> below, look like the server just not responds anymore which cause the client
> to be stalled. There are no more logs regarding SASL handshake.
> Used server is qdrouter.
> Would it make sense from your point of view to introduce a timeout here? Or
> is the responsibility for this in the calling application?
> {code}
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> io.netty.handler.ssl.SslHandler - [id: 0x429f2c43, L:/100.100.0.6:45982 -
> R:xxx.com/xxx:443] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
> state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
> 08:32:49.418 [vert.x-eventloop-thread-0] TRACE
> io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> {code}
> Thanks
> Daniel
--
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] (DISPATCH-1256) Throughput gets worse as more routers are added
[ https://issues.apache.org/jira/browse/DISPATCH-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned DISPATCH-1256: - Assignee: Ted Ross > Throughput gets worse as more routers are added > --- > > Key: DISPATCH-1256 > URL: https://issues.apache.org/jira/browse/DISPATCH-1256 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Alan Conway >Assignee: Ted Ross >Priority: Major > Attachments: reproducer.tgz > > > Creating a chain of routers gives worse throughput as the chain gets longer. > Reproducer: > Install quiver from here: https://github.com/alanconway/quiver (extened with > --send-url) > Run the attached script like this: > qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme > //:10004/testme > Sets up a chain of 4 routers, each connected to the previous. Waits for > qdstat -nv at router 1 to show 4 routers in the topology. Receive messages > from address 'testme' at router 4, send to address 'testme' at router 1. > This runs the routers with enough tracing to run the dispatch scraper tool, > which may affect the results. However 1 million message runs without tracing > show a drop-off in throughput going from 1m0 (no router) up to 1m4 (4-router > chain) - the more routers the worse it gets. This seems consistent with the > credit delays seen in the traced case. > 1m0/out.txt:End-to-end rate . 296,824 > messages/s > 1m0/out.txt: 50% 2 ms 99.90% 6 ms > 1m1/out.txt:End-to-end rate . 133,851 > messages/s > 1m1/out.txt: 50% 1 ms 99.90% 3 ms > 1m2/out.txt:End-to-end rate .. 59,011 > messages/s > 1m2/out.txt: 50% 2 ms 99.90% 8 ms > 1m3/out.txt:End-to-end rate .. 42,146 > messages/s > 1m3/out.txt: 50% 3 ms 99.90% ... 11 ms > 1m4/out.txt:End-to-end rate .. 32,415 > messages/s > 1m4/out.txt: 50% 4 ms 99.90% ... 13 ms > The output (config, logs and scrapes) from a 1000-message, 4-router tracing > run is included, as well as the script to generate new data. Runs of 10k > messages are feasible, but the HTML gets large and slow to view. From my > experiments the results are similar. > From file:scrape.html#c_connections the sender connection is starved of > credit far more than any other connection: 20x more starvation instances, 40x > longer total starvation and 100x longer wait for initial credit. > Overall the flow of credit is slower than the flow of messages, and each > additional router is reducing the throughput of credits, which reduces > message throughput. > Observations: > - initial credit delay is excessive (100ms in this case when worst-case > message latency is 33ms), something is wrong there. > - inter-router link credit is small (250) compared to application credit > (1000). Giving full credit to a sender creates a credit sharing problem, > but we could give full credit to the inter-router links. > - re-evaluate our credit sharing strategy to perform better in the common > unshared case. > Extracts from scrape: > ◊ 2019-01-23 13:55:16.524477 D0#141 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (0,1000) > ◊ 2019-01-23 13:55:16.633700 A0#287 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (0,250) > Initial delay 109ms, much worse than worst-case message latency of 33ms > ◊ 2019-01-23 13:55:16.639758 D0#153 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (3,1000) > ◊ 2019-01-23 13:55:16.642682 A0#543 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (168,85) > ◊ 2019-01-23 13:55:16.645205 D0#163 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (5,1000) > ◊ 2019-01-23 13:55:16.645448 D0#167 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (6,1000) > ◊ 2019-01-23 13:55:16.646510 A0#713 1 [A0_6] <- [] quiver-sender-3db6ad3f > transfer [0,0] (252) transfer_281 - 158 bytes no more credit (accepted > settled 0.028323 S) > ◊ 2019-01-23 13:55:16.647142 D0#193 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (7,1000) > ◊ 2019-01-23 13:55:16.647198 D0#195 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (10,1000) > ◊ 2019-01-23 13:55:16.647915 D0#214 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (16,1000) > ◊ 2019-01-23 13:55:16.648060 D0#217 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (25,1000) > ◊ 2019-01-23 13:55:16.651294 D0#239 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (28,1000) > ◊ 2019-01-23 13:55:16.652235 D0#257 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (41,1000) > ◊ 2019-01-23 13:55:16.654294 A0#802 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (253,9) credit restored > Here we see th
[jira] [Updated] (DISPATCH-1256) Throughput gets worse as more routers are added
[ https://issues.apache.org/jira/browse/DISPATCH-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-1256: -- Attachment: reproducer.tgz > Throughput gets worse as more routers are added > --- > > Key: DISPATCH-1256 > URL: https://issues.apache.org/jira/browse/DISPATCH-1256 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Alan Conway >Priority: Major > Attachments: reproducer.tgz > > > Creating a chain of routers gives worse throughput as the chain gets longer. > Reproducer: > Install quiver from here: https://github.com/alanconway/quiver (extened with > --send-url) > Run the attached script like this: > qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme > //:10004/testme > Sets up a chain of 4 routers, each connected to the previous. Waits for > qdstat -nv at router 1 to show 4 routers in the topology. Receive messages > from address 'testme' at router 4, send to address 'testme' at router 1. > This runs the routers with enough tracing to run the dispatch scraper tool, > which may affect the results. However 1 million message runs without tracing > show a drop-off in throughput going from 1m0 (no router) up to 1m4 (4-router > chain) - the more routers the worse it gets. This seems consistent with the > credit delays seen in the traced case. > 1m0/out.txt:End-to-end rate . 296,824 > messages/s > 1m0/out.txt: 50% 2 ms 99.90% 6 ms > 1m1/out.txt:End-to-end rate . 133,851 > messages/s > 1m1/out.txt: 50% 1 ms 99.90% 3 ms > 1m2/out.txt:End-to-end rate .. 59,011 > messages/s > 1m2/out.txt: 50% 2 ms 99.90% 8 ms > 1m3/out.txt:End-to-end rate .. 42,146 > messages/s > 1m3/out.txt: 50% 3 ms 99.90% ... 11 ms > 1m4/out.txt:End-to-end rate .. 32,415 > messages/s > 1m4/out.txt: 50% 4 ms 99.90% ... 13 ms > The output (config, logs and scrapes) from a 1000-message, 4-router tracing > run is included, as well as the script to generate new data. Runs of 10k > messages are feasible, but the HTML gets large and slow to view. From my > experiments the results are similar. > From file:scrape.html#c_connections the sender connection is starved of > credit far more than any other connection: 20x more starvation instances, 40x > longer total starvation and 100x longer wait for initial credit. > Overall the flow of credit is slower than the flow of messages, and each > additional router is reducing the throughput of credits, which reduces > message throughput. > Observations: > - initial credit delay is excessive (100ms in this case when worst-case > message latency is 33ms), something is wrong there. > - inter-router link credit is small (250) compared to application credit > (1000). Giving full credit to a sender creates a credit sharing problem, > but we could give full credit to the inter-router links. > - re-evaluate our credit sharing strategy to perform better in the common > unshared case. > Extracts from scrape: > ◊ 2019-01-23 13:55:16.524477 D0#141 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (0,1000) > ◊ 2019-01-23 13:55:16.633700 A0#287 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (0,250) > Initial delay 109ms, much worse than worst-case message latency of 33ms > ◊ 2019-01-23 13:55:16.639758 D0#153 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (3,1000) > ◊ 2019-01-23 13:55:16.642682 A0#543 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (168,85) > ◊ 2019-01-23 13:55:16.645205 D0#163 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (5,1000) > ◊ 2019-01-23 13:55:16.645448 D0#167 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (6,1000) > ◊ 2019-01-23 13:55:16.646510 A0#713 1 [A0_6] <- [] quiver-sender-3db6ad3f > transfer [0,0] (252) transfer_281 - 158 bytes no more credit (accepted > settled 0.028323 S) > ◊ 2019-01-23 13:55:16.647142 D0#193 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (7,1000) > ◊ 2019-01-23 13:55:16.647198 D0#195 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (10,1000) > ◊ 2019-01-23 13:55:16.647915 D0#214 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (16,1000) > ◊ 2019-01-23 13:55:16.648060 D0#217 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (25,1000) > ◊ 2019-01-23 13:55:16.651294 D0#239 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (28,1000) > ◊ 2019-01-23 13:55:16.652235 D0#257 4 [D0_3] <- [] quiver-receiver-2ebb30e5 > flow [0,0] (41,1000) > ◊ 2019-01-23 13:55:16.654294 A0#802 1 [A0_6] -> [] quiver-sender-3db6ad3f > flow [0,0] (253,9) credit restored > Here we see that the receiver has given 9 cre
[jira] [Created] (DISPATCH-1256) Throughput gets worse as more routers are added
Alan Conway created DISPATCH-1256: - Summary: Throughput gets worse as more routers are added Key: DISPATCH-1256 URL: https://issues.apache.org/jira/browse/DISPATCH-1256 Project: Qpid Dispatch Issue Type: Bug Reporter: Alan Conway Creating a chain of routers gives worse throughput as the chain gets longer. Reproducer: Install quiver from here: https://github.com/alanconway/quiver (extened with --send-url) Run the attached script like this: qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme //:10004/testme Sets up a chain of 4 routers, each connected to the previous. Waits for qdstat -nv at router 1 to show 4 routers in the topology. Receive messages from address 'testme' at router 4, send to address 'testme' at router 1. This runs the routers with enough tracing to run the dispatch scraper tool, which may affect the results. However 1 million message runs without tracing show a drop-off in throughput going from 1m0 (no router) up to 1m4 (4-router chain) - the more routers the worse it gets. This seems consistent with the credit delays seen in the traced case. 1m0/out.txt:End-to-end rate . 296,824 messages/s 1m0/out.txt: 50% 2 ms 99.90% 6 ms 1m1/out.txt:End-to-end rate . 133,851 messages/s 1m1/out.txt: 50% 1 ms 99.90% 3 ms 1m2/out.txt:End-to-end rate .. 59,011 messages/s 1m2/out.txt: 50% 2 ms 99.90% 8 ms 1m3/out.txt:End-to-end rate .. 42,146 messages/s 1m3/out.txt: 50% 3 ms 99.90% ... 11 ms 1m4/out.txt:End-to-end rate .. 32,415 messages/s 1m4/out.txt: 50% 4 ms 99.90% ... 13 ms The output (config, logs and scrapes) from a 1000-message, 4-router tracing run is included, as well as the script to generate new data. Runs of 10k messages are feasible, but the HTML gets large and slow to view. From my experiments the results are similar. >From file:scrape.html#c_connections the sender connection is starved of credit >far more than any other connection: 20x more starvation instances, 40x longer >total starvation and 100x longer wait for initial credit. Overall the flow of credit is slower than the flow of messages, and each additional router is reducing the throughput of credits, which reduces message throughput. Observations: - initial credit delay is excessive (100ms in this case when worst-case message latency is 33ms), something is wrong there. - inter-router link credit is small (250) compared to application credit (1000). Giving full credit to a sender creates a credit sharing problem, but we could give full credit to the inter-router links. - re-evaluate our credit sharing strategy to perform better in the common unshared case. Extracts from scrape: ◊ 2019-01-23 13:55:16.524477 D0#141 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (0,1000) ◊ 2019-01-23 13:55:16.633700 A0#287 1 [A0_6] -> [] quiver-sender-3db6ad3f flow [0,0] (0,250) Initial delay 109ms, much worse than worst-case message latency of 33ms ◊ 2019-01-23 13:55:16.639758 D0#153 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (3,1000) ◊ 2019-01-23 13:55:16.642682 A0#543 1 [A0_6] -> [] quiver-sender-3db6ad3f flow [0,0] (168,85) ◊ 2019-01-23 13:55:16.645205 D0#163 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (5,1000) ◊ 2019-01-23 13:55:16.645448 D0#167 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (6,1000) ◊ 2019-01-23 13:55:16.646510 A0#713 1 [A0_6] <- [] quiver-sender-3db6ad3f transfer [0,0] (252) transfer_281 - 158 bytes no more credit (accepted settled 0.028323 S) ◊ 2019-01-23 13:55:16.647142 D0#193 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (7,1000) ◊ 2019-01-23 13:55:16.647198 D0#195 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (10,1000) ◊ 2019-01-23 13:55:16.647915 D0#214 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (16,1000) ◊ 2019-01-23 13:55:16.648060 D0#217 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (25,1000) ◊ 2019-01-23 13:55:16.651294 D0#239 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (28,1000) ◊ 2019-01-23 13:55:16.652235 D0#257 4 [D0_3] <- [] quiver-receiver-2ebb30e5 flow [0,0] (41,1000) ◊ 2019-01-23 13:55:16.654294 A0#802 1 [A0_6] -> [] quiver-sender-3db6ad3f flow [0,0] (253,9) credit restored Here we see that the receiver has given 9 credit responses in the same time that the front router only gave 2. Either the router is slow to forward messages, or it's not giving back credit quickly when it does (or both) See flow.txt for the complete history of flow events at the sender and receiver, scrape.html for the complete history of everything. -- This message was sent by Atlassian JIRA (v7.6.3#76005) -
[jira] [Reopened] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reopened DISPATCH-1249:
---
I have now seen this happening even after waiting for topology to stabilize.
I'm not sure what the circumstances are - I'm seeing it in scenarios that
worked before and I'm sure what might have changed.
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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] (DISPATCH-1254) qdstat sometimes raises "TypeError: 'NoneType' object is not iterable"
[
https://issues.apache.org/jira/browse/DISPATCH-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1254:
--
Description:
Calling qdstat -nv repeatedly to check the status of a router network sometimes
raises a "nonetype not iterable error.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
//:10001/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
While waiting for the router network to stabilize I see output like the
following. The initial connection error is expected as the router has not yet
started, but the TypeError in the middle is unexpected.
{{ConnectionException: Connection amqp://localhost:10001/$management
disconnected: Condition('proton:io', 'recv: errno: 111') }}
{{waiting... }}
{{Routers in the Network }}
{{ router-id next-hop link ver cost neighbors valid-origins }}
{{ }}
{{ 1 (self) - 1 [] [] }}
{{waiting... }}
{{Routers in the Network }}
{{ router-id next-hop link ver cost neighbors valid-origins }}
{{ }}
{{ 1 (self) - 1 [] [] }}
{{waiting... }}
{{Routers in the Network }}
{{ router-id next-hop link ver cost neighbors valid-origins }}
{{ }}
{{ 1 (self) - 1 [] [] }}
{{waiting... }}
{{TypeError: 'NoneType' object is not iterable }}
{{waiting... }}
{{Routers in the Network }}
{{Last Topology Change: Wednesday Jan 23 15:40:34 2019 GMT }}
{{ router-id next-hop link ver cost neighbors valid-origins }}
{{ = }}
{{ 1 (self) - 1 ['2'] [] }}
{{ 2 - 0 1 1 ['1', '3'] [] }}
{{ 3 2 - 2 [] [] }}
{{waiting... }}
{{Routers in the Network }}
{{Last Topology Change: Wednesday Jan 23 15:40:39 2019 GMT }}
{{ router-id next-hop link ver cost neighbors valid-origins }}
{{ = }}
{{ 1 (self) - 1 ['2'] [] }}
{{ 2 - 0 1 1 ['1', '3'] [] }}
{{ 3 2 - 1 2 ['2', '4'] [] }}
{{ 4 2 - 1 3 ['3'] [] }}
was:
Calling qdstat -nv repeatedly to check the status of a router network sometimes
raises a "nonetype not iterable error.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/x //:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/testme //:10004/testme
> qdstat sometimes raises "TypeError: 'NoneType' object is not iterable"
> --
>
> Key: DISPATCH-1254
> URL: https://issues.apache.org/jira/browse/DISPATCH-1254
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Calling qdstat -nv repeatedly to check the status of a router network
> sometimes raises a "nonetype not iterable error.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quive
[jira] [Updated] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1249:
--
Attachment: qdr-chain.sh
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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] (DISPATCH-1254) qdstat sometimes raises "TypeError: 'NoneType' object is not iterable"
[
https://issues.apache.org/jira/browse/DISPATCH-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1254:
--
Description:
Calling qdstat -nv repeatedly to check the status of a router network sometimes
raises a "nonetype not iterable error.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/x //:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/testme //:10004/testme
was:
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/x //:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/testme //:10004/testme
> qdstat sometimes raises "TypeError: 'NoneType' object is not iterable"
> --
>
> Key: DISPATCH-1254
> URL: https://issues.apache.org/jira/browse/DISPATCH-1254
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Calling qdstat -nv repeatedly to check the status of a router network
> sometimes raises a "nonetype not iterable error.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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-1254) qdstat sometimes raises "TypeError: 'NoneType' object is not iterable"
Alan Conway created DISPATCH-1254:
-
Summary: qdstat sometimes raises "TypeError: 'NoneType' object is
not iterable"
Key: DISPATCH-1254
URL: https://issues.apache.org/jira/browse/DISPATCH-1254
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 1.2.0
Reporter: Alan Conway
Assignee: Ganesh Murthy
Attachments: qdr-chain.sh
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/x //:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/testme //:10004/testme
--
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-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved DISPATCH-1249.
---
Resolution: Not A Bug
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750142#comment-16750142
]
Alan Conway commented on DISPATCH-1249:
---
Updated qdr-chain.sh, no need for static address config.
In earlier experiments I saw messages being rejected unless an address was
statically configured on all routers, but this only happens if the
sender/receiver are started before the network topology has settled, so it is
probably expected behavior.
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1249:
--
Attachment: (was: qdr-chain.sh)
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
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] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1249:
--
Description:
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/x //:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
//:10001/testme //:10004/testme
was:
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
//:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
//:10004/testme
NOTE: you may need to add --timeout 60 to the quiver command if the test
doesn't complete within the default 10sec timeout.
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/x //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --timeout 60 --arrow c --count 1000 --send-url
> //:10001/testme //:10004/testme
>
--
This messag
[jira] [Updated] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1249:
--
Description:
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
//:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
//:10004/testme
NOTE: you may need to add --timeout 60 to the quiver command if the test
doesn't complete within the default 10sec timeout.
was:
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
//:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
//:10004/testme
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
> //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
> //:10004/testme
> NOTE: you may need to add --timeout 60 to the quiver command if the te
[jira] [Updated] (DISPATCH-1249) Rejected messages in a 4-router chain
[
https://issues.apache.org/jira/browse/DISPATCH-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated DISPATCH-1249:
--
Attachment: qdr-chain.sh
> Rejected messages in a 4-router chain
> -
>
> Key: DISPATCH-1249
> URL: https://issues.apache.org/jira/browse/DISPATCH-1249
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.2.0
>Reporter: Alan Conway
>Priority: Major
> Attachments: qdr-chain.sh
>
>
> Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
> -nv at router 1 to show 4 routers in the known topology. Receive messages
> from address x at router 4, send to address x from router 1. Messages are
> rejected at the sender.
> Reproducer:
> make install this version of quiver (extented to allow separate send/receive
> URLS). If you have maven installed you should edit the makefile to disable
> the Java arrow as the build is very slow and fragile:
> [https://github.com/alanconway/quiver]
> run the attached script like this:
> qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
> //:10004/x
> The script generates config files, starts four routers, waits for qdstat -nv
> to show the full topology and then runs quiver as directed. Edit the script
> to change logging or other config settings. Log and config files are created
> in the current directory.
> WARNING the script will kill any running qdrouterd.
> I see the sender fail with this error:
> impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
> pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
> local=unknown, remote=rejected}
> NOTE: the script configures the address "testme" on all 4 routers, if you run
> the test like this it passes:
> qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
> //:10004/testme
>
--
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-1249) Rejected messages in a 4-router chain
Alan Conway created DISPATCH-1249:
-
Summary: Rejected messages in a 4-router chain
Key: DISPATCH-1249
URL: https://issues.apache.org/jira/browse/DISPATCH-1249
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 1.2.0
Reporter: Alan Conway
Set up a chain of 4 routers, each connected to the previous. Wait for qdstat
-nv at router 1 to show 4 routers in the known topology. Receive messages from
address x at router 4, send to address x from router 1. Messages are rejected
at the sender.
Reproducer:
make install this version of quiver (extented to allow separate send/receive
URLS). If you have maven installed you should edit the makefile to disable the
Java arrow as the build is very slow and fragile:
[https://github.com/alanconway/quiver]
run the attached script like this:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/x
//:10004/x
The script generates config files, starts four routers, waits for qdstat -nv to
show the full topology and then runs quiver as directed. Edit the script to
change logging or other config settings. Log and config files are created in
the current directory.
WARNING the script will kill any running qdrouterd.
I see the sender fail with this error:
impls/quiver-arrow-qpid-proton-c.c:307: bad delivery:
pn_delivery<0x8aad20>\{sending, tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
local=unknown, remote=rejected}
NOTE: the script configures the address "testme" on all 4 routers, if you run
the test like this it passes:
qdr-chain.sh quiver --arrow c --count 1000 --send-url //:10001/testme
//:10004/testme
--
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-1988) [cpp] streamable message support
[ https://issues.apache.org/jira/browse/PROTON-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1988: --- Assignee: Alan Conway > [cpp] streamable message support > > > Key: PROTON-1988 > URL: https://issues.apache.org/jira/browse/PROTON-1988 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > C++ API support for streaming large messages in chunks (too large to fit > entire message in memory) > The C link-level API does support streaming messages in chunks, but the C > message encoder/decoder and the proton::message type do. Provide an > alternative (or extended) C++ message type with a byte-stream API to > send/receive the body data in chunks, without every requiring the entire body > to be held in memory. > Use cases: > # Only the message body need be streamed. Properties are encoded/decode as a > unit before sending/receiving any of the body. Most client/endpoint > applications would work this way. > # The entire message, headers, properties and all, need to be streamed, with > support for partial decoding of an incoming message and efficient pass thru > (incoming to outgoing without decode/re-encode). Only advanced intermediaries > are likely to need this (e.g. this is what dispatch router does.) > > > -- 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-1988) [cpp] streamable message support
[
https://issues.apache.org/jira/browse/PROTON-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736123#comment-16736123
]
Alan Conway commented on PROTON-1988:
-
Partial sketch of an API, to get discussion started - nothing final here.
Receiving:
{code:java}
on_delivery_start(delivery& d, streaming_message& m) { new message begins }
on_delivery_more(delivery& d, streaming_message& m) { more arrives }
// Above are only called if on_message() is NOT implemented.
{code}
Sending:
{code:java}
on_sendable(sender s) {
streaming_message sm;
tracker = s.start_sending(sm);
// maybe send initial data here...
}
on_tracker_sendable(tracker& t, streaming_message& m) { send more data }
{code}
Pass thru: pass streaming_message from on_delivery_start() to
sender::start_sending, implement on_tracker_sendable() to send to credit. No
need to implement on_delivery_more() since you can't do anything till it's
possible to send.
API extensions:
delivery: read incoming data, check message complete/aborted status.
tracker: write outgoing data, abort message in progress.
streaming_messge: append data (from delivery or app), pop data to write (to
tracker or app). Buffer incoming/outgoing data. Methods to construct/access
message properties.
Need to think about buffer ownership and copies for send/receive ops.
check incoming delivery for more data, end of message, aborted message - on
delivery not streamable_message as it only applies to inbound
* allow sender to abort message before completion.
* For use case 1. (no streaming of headers) the API could be identical to
existing proton::message, but without body() setters/getters and with extra
streaming methods.
* For use case 2 we could possibly use the same API with a "progress
indicator" that says which message properties are available and decodes on
demand (dispatch does this) but we might want a different API here, maybe more
SAX-like.
Flow control: proton should obey session byte flow control i.e. no calls to
tracker_sendable unless we have session space. We should provide indication to
user of how much session space there is. We may allow the user to exceed
session space temporarily if they provide the buffers. The user can implement
whatever other per-message limits they want.
> [cpp] streamable message support
>
>
> Key: PROTON-1988
> URL: https://issues.apache.org/jira/browse/PROTON-1988
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.26.0
>Reporter: Alan Conway
>Priority: Major
>
> C++ API support for streaming large messages in chunks (too large to fit
> entire message in memory)
> The C link-level API does support streaming messages in chunks, but the C
> message encoder/decoder and the proton::message type do. Provide an
> alternative (or extended) C++ message type with a byte-stream API to
> send/receive the body data in chunks, without every requiring the entire body
> to be held in memory.
> Use cases:
> # Only the message body need be streamed. Properties are encoded/decode as a
> unit before sending/receiving any of the body. Most client/endpoint
> applications would work this way.
> # The entire message, headers, properties and all, need to be streamed, with
> support for partial decoding of an incoming message and efficient pass thru
> (incoming to outgoing without decode/re-encode). Only advanced intermediaries
> are likely to need this (e.g. this is what dispatch router does.)
>
>
>
--
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-1988) [cpp] streamable message support
Alan Conway created PROTON-1988: --- Summary: [cpp] streamable message support Key: PROTON-1988 URL: https://issues.apache.org/jira/browse/PROTON-1988 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: proton-c-0.26.0 Reporter: Alan Conway C++ API support for streaming large messages in chunks (too large to fit entire message in memory) The C link-level API does support streaming messages in chunks, but the C message encoder/decoder and the proton::message type do. Provide an alternative (or extended) C++ message type with a byte-stream API to send/receive the body data in chunks, without every requiring the entire body to be held in memory. Use cases: # Only the message body need be streamed. Properties are encoded/decode as a unit before sending/receiving any of the body. Most client/endpoint applications would work this way. # The entire message, headers, properties and all, need to be streamed, with support for partial decoding of an incoming message and efficient pass thru (incoming to outgoing without decode/re-encode). Only advanced intermediaries are likely to need this (e.g. this is what dispatch router does.) -- 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-1987) [cpp] Encode/decode all legal message body types.
[ https://issues.apache.org/jira/browse/PROTON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1987: --- Assignee: Alan Conway > [cpp] Encode/decode all legal message body types. > - > > Key: PROTON-1987 > URL: https://issues.apache.org/jira/browse/PROTON-1987 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > From AMQP spec > [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format] > _The body consists of one of the following three choices:_ > # _one or more > [data|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-data] > sections,_ > # _one or more > [amqp-sequence|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-sequence] > sections,_ > # _or a single > [amqp-value|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-value] > section._ > It actually *is* currently possible to encode and decode all these body > formats using a combination of AMQP value types and the message::inferred() > flag. However, they way it works is not intuitive, and it is easy to encode > an illegal body format (e.g. mix section types) which won't be detected till > runtime. > A better API should: > * Make it easy to set/determine the body encoding style. > * Type safe API that can only encode legal body formats. > -- 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-1987) [cpp] Encode/decode all legal message body types.
Alan Conway created PROTON-1987: --- Summary: [cpp] Encode/decode all legal message body types. Key: PROTON-1987 URL: https://issues.apache.org/jira/browse/PROTON-1987 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: proton-c-0.26.0 Reporter: Alan Conway >From AMQP spec >[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format] _The body consists of one of the following three choices:_ # _one or more [data|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-data] sections,_ # _one or more [amqp-sequence|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-sequence] sections,_ # _or a single [amqp-value|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-amqp-value] section._ It actually *is* currently possible to encode and decode all these body formats using a combination of AMQP value types and the message::inferred() flag. However, they way it works is not intuitive, and it is easy to encode an illegal body format (e.g. mix section types) which won't be detected till runtime. A better API should: * Make it easy to set/determine the body encoding style. * Type safe API that can only encode legal body formats. -- 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-985) Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock time
[ https://issues.apache.org/jira/browse/PROTON-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721807#comment-16721807 ] Alan Conway commented on PROTON-985: Easiest. Fix. Ever. transport_tick always needed to be fed from a monotonic clock, changed the parameter type and updated the docs to make that clear. > Modify pn_transport_tick to explicitly use a monotonic clock, not wall clock > time > - > > Key: PROTON-985 > URL: https://issues.apache.org/jira/browse/PROTON-985 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-0.10 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: proton-c-future > > > The timestamp argument to pn_transport_tick is a pn_timestamp_t. > pn_timestamp_t implies real time (wall clock) in that it's expressed as a > time value based on epoch. > As seen in QPID-6698, using a real time value for that argument can lead to > problems if the real time is adjusted (eg. timezone, daylight savings, > drift). > Instead, pn_transport_tick should be passed a monotonic clock source - one > that does not reflect changes in real time. > All documentation and examples should be updated accordingly. -- 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-1981) [cpp] timestamp::now() returns wrong value
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1981. - Resolution: Fixed > [cpp] timestamp::now() returns wrong value > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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-1981) [cpp] timestamp::now() returns wrong value
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1981: Summary: [cpp] timestamp::now() returns wrong value (was: Wrong posix time for pn_proactor_now()) > [cpp] timestamp::now() returns wrong value > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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] [Comment Edited] (PROTON-1981) Wrong posix time for pn_proactor_now()
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16718312#comment-16718312 ] Alan Conway edited comment on PROTON-1981 at 12/12/18 1:08 AM: --- C++ timestamp::now() implementation is definitely faulty. Annoying portability dance required, see https://github.com/alanconway/qpid-proton/blob/master/c/src/platform/platform.c#L55 In C\+\+11 we could use std::chrono but as long as we have to handle C\+\+03 I think we should do it the smelly old way. was (Author: aconway): C++ timestamp::now() implementation is definitely faulty. Annoying portability dance required, see https://github.com/alanconway/qpid-proton/blob/master/c/src/platform/platform.c#L55 In C++11 we could use std::chrono but as long as we have to handle C++03 I think we should do it the smelly old way. > Wrong posix time for pn_proactor_now() > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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-1981) Wrong posix time for pn_proactor_now()
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16718312#comment-16718312 ] Alan Conway commented on PROTON-1981: - C++ timestamp::now() implementation is definitely faulty. Annoying portability dance required, see https://github.com/alanconway/qpid-proton/blob/master/c/src/platform/platform.c#L55 In C++11 we could use std::chrono but as long as we have to handle C++03 I think we should do it the smelly old way. > Wrong posix time for pn_proactor_now() > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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-1982) Proton C build fails on debian:stretch
[ https://issues.apache.org/jira/browse/PROTON-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16718318#comment-16718318 ] Alan Conway commented on PROTON-1982: - I get identical symptoms "cannot determine linkage" if I build on a system with no C++ compiler. The above commit skips C tests that need a C\+\+ compiler if there isn't one, if it fixes the debian problem, please resolve this JIRA. > Proton C build fails on debian:stretch > -- > > Key: PROTON-1982 > URL: https://issues.apache.org/jira/browse/PROTON-1982 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 >Reporter: Cliff Jansen >Priority: Major > > Using master, CMake fails with: > > CMake Error: CMake can not determine linker language for target: c-core-test > CMake Error: Cannot determine link language for target "c-core-test". > CMake Error: CMake can not determine linker language for target: c-extra-test > CMake Error: Cannot determine link language for target "c-extra-test". > CMake Error: CMake can not determine linker language for target: > c-proactor-test > CMake Error: Cannot determine link language for target "c-proactor-test". > > run command: > > cmake -DBUILD_GO=ON -DBUILD_CPP=OFF -DBUILD_PYTHON=OFF > -DBUILD_STATIC_LIBS=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release > > also fails with same error messages with simplfied args > > cmake -DBUILD_GO=ON -DCMAKE_BUILD_TYPE=Release .. > > This appears to be platform specific > -- 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-1981) Wrong posix time for pn_proactor_now()
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16715895#comment-16715895 ] Alan Conway commented on PROTON-1981: - Timekeeping is really not our business - I can see why Andrew added it to the C proactor for our own use, since portable time is such a pain in C, but in other bindings we should be using the language-standard time APIs. C++03 is no better than C (sigh) but C++11 is, and Go has excellent time support. In any case we should definitely make sure any C++ time APIs we have lumbered ourselves with behave as documented. The Go binding uses the standard Go Time type, and does all the required conversions to/from AMQP-epoch-ms-time when encoding/decoding. The Go Time type cleverly includes both a wall-clock *and* a monotonic timestamp and automatically Does the Right Thing when you compute durations or format printable time-stamps, so you can pretty much forget about that distinction in Go. > Wrong posix time for pn_proactor_now() > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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] [Comment Edited] (PROTON-1981) Wrong posix time for pn_proactor_now()
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16715895#comment-16715895 ] Alan Conway edited comment on PROTON-1981 at 12/11/18 1:13 AM: --- Timekeeping is really not our business - I can see why Andrew added it to the C proactor for our own use, since portable time is such a pain in C, but in other bindings we should be using the language-standard time APIs. C+++03 is no better than C (sigh) but C++11 is, and Go has excellent time support. In any case we should definitely make sure any C+++ time APIs we have lumbered ourselves with behave as documented. The Go binding uses the standard Go Time type, and does all the required conversions to/from AMQP-epoch-ms-time when encoding/decoding. The Go Time type cleverly includes both a wall-clock *and* a monotonic timestamp and automatically Does the Right Thing when you compute durations or format printable time-stamps, so you can pretty much forget about that distinction in Go. was (Author: aconway): Timekeeping is really not our business - I can see why Andrew added it to the C proactor for our own use, since portable time is such a pain in C, but in other bindings we should be using the language-standard time APIs. C++03 is no better than C (sigh) but C++11 is, and Go has excellent time support. In any case we should definitely make sure any C++ time APIs we have lumbered ourselves with behave as documented. The Go binding uses the standard Go Time type, and does all the required conversions to/from AMQP-epoch-ms-time when encoding/decoding. The Go Time type cleverly includes both a wall-clock *and* a monotonic timestamp and automatically Does the Right Thing when you compute durations or format printable time-stamps, so you can pretty much forget about that distinction in Go. > Wrong posix time for pn_proactor_now() > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- 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-1976) [cpp] add messaging_handler::add on_connection_start()
Alan Conway created PROTON-1976: --- Summary: [cpp] add messaging_handler::add on_connection_start() Key: PROTON-1976 URL: https://issues.apache.org/jira/browse/PROTON-1976 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: proton-c-0.26.0 Reporter: Alan Conway Fix For: proton-c-future Add messaging_handler::on_connection_start() to be called once before any protocol exchanges for the connection have take place. This can be used for per-connection set-up including pipelined opens of sessions and links to be sent with the initial OPEN frame. This was added and then removed due to binary compatibility issues, see PROTON-1959 -- 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-1975) Review Breaking Changes.
Alan Conway created PROTON-1975: --- Summary: Review Breaking Changes. Key: PROTON-1975 URL: https://issues.apache.org/jira/browse/PROTON-1975 Project: Qpid Proton Issue Type: Task Reporter: Alan Conway Fix For: proton-c-future A breaking change is any change that would make user code that was valid for a previous releases malfunction or fail to compile with a new release. Jiras for future breaking changes should be linked to this one as a reminder, and reviewed when we get to a suitable release to include such changes. -- 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] [Reopened] (PROTON-1959) [c,cpp] API additions to simplify reconnect
[ https://issues.apache.org/jira/browse/PROTON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened PROTON-1959: - This fix is binary incompatible with 0.26, it introduces new virtual functions on messaging_handler, which is subclassed in user code and called by the library. Replace with a compatible fix for 0.27 and schedule incompatible changes for a future binary release. > [c,cpp] API additions to simplify reconnect > --- > > Key: PROTON-1959 > URL: https://issues.apache.org/jira/browse/PROTON-1959 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > Add some minor API extensions to make it easier to tell if a connection is > reconnecting, and to set up one-time events that only happen on the initial > connect. -- 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-1887) [c] Introduce external C test harness for C tests
[ https://issues.apache.org/jira/browse/PROTON-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1887. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > [c] Introduce external C test harness for C tests > - > > Key: PROTON-1887 > URL: https://issues.apache.org/jira/browse/PROTON-1887 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.24.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > Investigate & choose an existing well-known C test framework for use in C > testing. > Port existing C tests from our local test macros to the new framework. > Long term we should migrate some of the tests in python that are really > testing the C core, but that is not part of this task. -- 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-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
To reproduce the problem see the comments in c/tests/pn_test_proactor.cpp in
function proactor::wait_next().
The fix to PROTON-1586 was to have the connection_driver batch to hide events
after TRANSPORT_CLOSE by returning NULL as if the batch were empty. However,
that is too late to prevent the batch being returned by the proactor - from the
proactors perspective it is not empty, it contains CONNECTION_LOCAL_CLOSE but
it looks empty to the user.
This is really a bug in the pn_connection_driver, not the proactor, and it
should be fixed there so that all proactors and non-proactor applications will
benefit.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
This is really a bug in the pn_connection_driver, not the proactor, and it
should be fixed there so that all proactors and non-proactor applications will
benefit.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> To reproduce the problem see the comments in c/tests/pn_test_proactor.cpp in
> function proactor::wait_next().
> The fix to PROTON-1586 was to have the connection_driver batch to hide events
> after TRANSPORT_CLOSE by returning NULL as if the batch were empty. However,
> that is too late to prevent the batch being returned by the proactor - from
> the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> This is really a bug in the pn_connection_driver, not the proactor, and it
> should be fixed there so that all proactors and non-proactor applications
> will benefit.
>
> Original reproducer:
> Run the send
[jira] [Updated] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
This is really a bug in the pn_connection_driver, not the proactor, and it
should be fixed there so that all proactors and non-proactor applications will
benefit.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
> c/tests/proactor_tests.cpp, read the comments there.
> The original fix to PROTON-1586 was to have the connection_driver batch to
> hide events after TRANSPORT_CLOSE by returning NULL as if the batch were
> empty. However, that is too late to prevent the batch being returned by the
> proactor - from the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> This is really a bug in the pn_connection_driver, not the proactor, and it
> should be fixed there so that all proactors and non-proactor applications
> will benefit.
> Original reproducer:
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy
[jira] [Updated] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
The original but
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
> c/tests/proactor_tests.cpp, read the comments there.
> The original fix to PROTON-1586 was to have the connection_driver batch to
> hide events after TRANSPORT_CLOSE by returning NULL as if the batch were
> empty. However, that is too late to prevent the batch being returned by the
> proactor - from the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> Original reproducer:
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy/opensource/qpid-proton/build
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$ examples/c/send nosuchhost
> PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
> to nosuchhost:5672
> epoll proactor failure in
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648:
> "arming polled file descriptor": No such file or directory
> Aborted (core dumped)
> [gmurthy@localhost build]$
> {noformat}
> The proactor code coredumps.
--
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-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The original but
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The original but
>
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy/opensource/qpid-proton/build
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$ examples/c/send nosuchhost
> PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
> to nosuchhost:5672
> epoll proactor failure in
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648:
> "arming polled file descriptor": No such file or directory
> Aborted (core dumped)
> [gmurthy@localhost build]$
> {noformat}
> The proactor code coredumps.
--
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-1964) [c] pn_proactor_wait() can return empty event batches.
Alan Conway created PROTON-1964:
---
Summary: [c] pn_proactor_wait() can return empty event batches.
Key: PROTON-1964
URL: https://issues.apache.org/jira/browse/PROTON-1964
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: proton-c-0.18.0
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
--
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-1960) [Go Electron] Unable to send a message larger than 16k in size
[ https://issues.apache.org/jira/browse/PROTON-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1960. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > [Go Electron] Unable to send a message larger than 16k in size > -- > > Key: PROTON-1960 > URL: https://issues.apache.org/jira/browse/PROTON-1960 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rob KIng >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > Unable to send a message larger than 16k in size from a sending program using > the Go electron bindings to the qpidd broker. Attempting to send a message of > this size causes the program to hang in the electron package. Some discussion > and some debug output from the broker can be found at > [http://qpid.2158936.n2.nabble.com/Go-Electron-Large-Messages-Fail-To-Send-td7680219.html] > Issue can be recreated using a slightly modified version of send.go in the > electron package [https://play.golang.org/p/2dQ4jdlKHKi] sending to qpidd > version 1.38 -- 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-1960) [Go Electron] Unable to send a message larger than 16k in size
[ https://issues.apache.org/jira/browse/PROTON-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673658#comment-16673658 ] Alan Conway commented on PROTON-1960: - The go1 branch is supposed to point at the latest official release, but I just realized it had fallen behind. I've just updated it to 0.26. Unfortunately the fix you need was made just after the 0.26 release, so it'll show up in 0.27. I'll take care not to dawdle on updating the go-get branch next time! The releases are pretty regular (every couple months or so), ask on the qpid-dev list for a more official estimate. > [Go Electron] Unable to send a message larger than 16k in size > -- > > Key: PROTON-1960 > URL: https://issues.apache.org/jira/browse/PROTON-1960 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rob KIng >Assignee: Alan Conway >Priority: Major > > Unable to send a message larger than 16k in size from a sending program using > the Go electron bindings to the qpidd broker. Attempting to send a message of > this size causes the program to hang in the electron package. Some discussion > and some debug output from the broker can be found at > [http://qpid.2158936.n2.nabble.com/Go-Electron-Large-Messages-Fail-To-Send-td7680219.html] > Issue can be recreated using a slightly modified version of send.go in the > electron package [https://play.golang.org/p/2dQ4jdlKHKi] sending to qpidd > version 1.38 -- 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-1960) [Go Electron] Unable to send a message larger than 16k in size
[ https://issues.apache.org/jira/browse/PROTON-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672564#comment-16672564 ] Alan Conway commented on PROTON-1960: - Can you please confirm the exact git commit you are testing with? I am easily able to reproduce this problem before this commit: 486fbaf0 * PROTON-1953: [go] occasional client/server hang with high volume of messages but for me the problem seems to be fixed after that commit. I am using qpidd 1.38, and go 1.11 > [Go Electron] Unable to send a message larger than 16k in size > -- > > Key: PROTON-1960 > URL: https://issues.apache.org/jira/browse/PROTON-1960 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rob KIng >Assignee: Alan Conway >Priority: Major > > Unable to send a message larger than 16k in size from a sending program using > the Go electron bindings to the qpidd broker. Attempting to send a message of > this size causes the program to hang in the electron package. Some discussion > and some debug output from the broker can be found at > [http://qpid.2158936.n2.nabble.com/Go-Electron-Large-Messages-Fail-To-Send-td7680219.html] > Issue can be recreated using a slightly modified version of send.go in the > electron package [https://play.golang.org/p/2dQ4jdlKHKi] sending to qpidd > version 1.38 -- 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-1960) [Go Electron] Unable to send a message larger than 16k in size
[ https://issues.apache.org/jira/browse/PROTON-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1960: --- Assignee: Alan Conway > [Go Electron] Unable to send a message larger than 16k in size > -- > > Key: PROTON-1960 > URL: https://issues.apache.org/jira/browse/PROTON-1960 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rob KIng >Assignee: Alan Conway >Priority: Major > > Unable to send a message larger than 16k in size from a sending program using > the Go electron bindings to the qpidd broker. Attempting to send a message of > this size causes the program to hang in the electron package. Some discussion > and some debug output from the broker can be found at > [http://qpid.2158936.n2.nabble.com/Go-Electron-Large-Messages-Fail-To-Send-td7680219.html] > Issue can be recreated using a slightly modified version of send.go in the > electron package [https://play.golang.org/p/2dQ4jdlKHKi] sending to qpidd > version 1.38 -- 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-1959) [c,cpp] API additions to simplify reconnect
[ https://issues.apache.org/jira/browse/PROTON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1959. - Resolution: Fixed > [c,cpp] API additions to simplify reconnect > --- > > Key: PROTON-1959 > URL: https://issues.apache.org/jira/browse/PROTON-1959 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.26.0 > > > Add some minor API extensions to make it easier to tell if a connection is > reconnecting, and to set up one-time events that only happen on the initial > connect. -- 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-1959) [c,cpp] API additions to simplify reconnect
[ https://issues.apache.org/jira/browse/PROTON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1959: Affects Version/s: proton-c-0.25.0 > [c,cpp] API additions to simplify reconnect > --- > > Key: PROTON-1959 > URL: https://issues.apache.org/jira/browse/PROTON-1959 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.26.0 > > > Add some minor API extensions to make it easier to tell if a connection is > reconnecting, and to set up one-time events that only happen on the initial > connect. -- 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
