[jira] [Commented] (QPID-8200) [linearstore] Compile error when compiling on Fedora 28
[
https://issues.apache.org/jira/browse/QPID-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494305#comment-16494305
]
Chris Richardson commented on QPID-8200:
I've also seen this problem on recent Gentoo versions due to the upgrade to gcc
8.x. Unfortunately I missed it in my previous round of gcc 8 fixes because I
forgot to include the optional linear store component :{
IIRC a fix is also required for the legacystore component - perhaps these could
be fixed under the same issue since I think the fixes will be very similar.
> [linearstore] Compile error when compiling on Fedora 28
> ---
>
> Key: QPID-8200
> URL: https://issues.apache.org/jira/browse/QPID-8200
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> When compiling on Fedora 28, a compile warning {{-Werror=class-memaccess}} is
> seen when compiling {{qpid::linearstore::journal::pmgr}} , and which was not
> seen on Fedora 27:
> {noformat}
> qpid::linearstore::journal::pmgr::initialize(qpid::linearstore::journal::aio_callback*,
> uint32_t, uint16_t)':
> /foo/cpp/src/qpid/linearstore/journal/pmgr.cpp:115:68: error: 'void*
> memset(void*, int, size_t)' clearing an object of non-trivial type 'struct
> qpid::linearstore::journal::pmgr::page_cb'; use assignment instead
> [-Werror=class-memaccess]
> std::memset(_page_cb_arr, 0, _cache_num_pages * sizeof(page_cb));
> ^
> In file included from /foo/cpp/src/qpid/linearstore/journal/pmgr.cpp:22:
> /foo/cpp/src/qpid/linearstore/journal/pmgr.h:63:12: note: 'struct
> qpid::linearstore::journal::pmgr::page_cb' declared here
> struct page_cb
> ^~~
> cc1plus: all warnings being treated as errors{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] [Updated] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts
[
https://issues.apache.org/jira/browse/DISPATCH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-937:
--
Fix Version/s: (was: 1.2.0)
> schema.validate(attributes) called 4 times before the router starts
> ---
>
> Key: DISPATCH-937
> URL: https://issues.apache.org/jira/browse/DISPATCH-937
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: dispatch-937-1_vhost-creation-1.txt
>
>
> Start the router with the config file etc/qdrouterd.conf. This config file
> has one router entity
> {noformat}
> router {
> mode: interior
> id: Router.A
> }{noformat}
>
> The schema.validate is called 4 times on the router entity. It should be
> called only once
>
> Here is the traceback of the 4 times it was called -
>
> {noformat}
> {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id':
> u'Router.A'}
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 142, in configure_dispatch
> config = Config(filename)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 41, in __init__
> self.load(filename, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 112, in load
> self.load(f, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 120, in load
> self.schema.validate_all(entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 576, in validate_all
> self.validate_add(a, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 53, in validate_add
> super(QdSchema, self).validate_add(attributes, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 585, in validate_add
> self.validate_entity(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 568, in validate_entity
> entity_type.validate(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
> configure(config.by_type('router')[0])
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 151, in configure
> agent.configure(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 855, in configure
> self._create(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 828, in _create
> self.add_entity(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 859, in add_entity
> self.entities.add(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 519, in add
> entity.validate() # Fill in defaults etc.
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 171, in validate
> super(EntityAdapter, self).validate(**kwargs)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 639, in validate
> self.entity_type.validate(self.attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
> configure(config.by_type('router')[0])
> File
>
[jira] [Closed] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts
[
https://issues.apache.org/jira/browse/DISPATCH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross closed DISPATCH-937.
-
Resolution: Won't Fix
There doesn't seem to be a compelling reason to optimize this.
> schema.validate(attributes) called 4 times before the router starts
> ---
>
> Key: DISPATCH-937
> URL: https://issues.apache.org/jira/browse/DISPATCH-937
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: dispatch-937-1_vhost-creation-1.txt
>
>
> Start the router with the config file etc/qdrouterd.conf. This config file
> has one router entity
> {noformat}
> router {
> mode: interior
> id: Router.A
> }{noformat}
>
> The schema.validate is called 4 times on the router entity. It should be
> called only once
>
> Here is the traceback of the 4 times it was called -
>
> {noformat}
> {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id':
> u'Router.A'}
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 142, in configure_dispatch
> config = Config(filename)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 41, in __init__
> self.load(filename, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 112, in load
> self.load(f, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 120, in load
> self.schema.validate_all(entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 576, in validate_all
> self.validate_add(a, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 53, in validate_add
> super(QdSchema, self).validate_add(attributes, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 585, in validate_add
> self.validate_entity(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 568, in validate_entity
> entity_type.validate(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
> configure(config.by_type('router')[0])
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 151, in configure
> agent.configure(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 855, in configure
> self._create(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 828, in _create
> self.add_entity(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 859, in add_entity
> self.entities.add(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 519, in add
> entity.validate() # Fill in defaults etc.
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 171, in validate
> super(EntityAdapter, self).validate(**kwargs)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 639, in validate
> self.entity_type.validate(self.attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in
[jira] [Updated] (DISPATCH-949) Exchange Binding loop detection
[ https://issues.apache.org/jira/browse/DISPATCH-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-949: -- Fix Version/s: (was: 1.2.0) Backlog > Exchange Binding loop detection > --- > > Key: DISPATCH-949 > URL: https://issues.apache.org/jira/browse/DISPATCH-949 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.1.0 >Reporter: Ken Giusti >Priority: Major > Fix For: Backlog > > > Since the exchange forwarder resets the valid origin and trace data included > in the message it is possible to introduce a message loop. > The exchange forwarder need to be able to detect and terminate routing loops. -- 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-950) qdstat should list exchange and binding details
[ https://issues.apache.org/jira/browse/DISPATCH-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-950: -- Fix Version/s: (was: 1.2.0) Backlog > qdstat should list exchange and binding details > --- > > Key: DISPATCH-950 > URL: https://issues.apache.org/jira/browse/DISPATCH-950 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tools >Affects Versions: 1.1.0 >Reporter: Ken Giusti >Priority: Major > Fix For: Backlog > > > It would be useful to have a new qdstat option to dump the exchange and > routing configuration. -- 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-1019) Messaging instability in networks with many clients / addresses.
[
https://issues.apache.org/jira/browse/DISPATCH-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Meulemans updated DISPATCH-1019:
---
Description:
After DISPATCH-966 has been fixed I am still experiencing problems in a network
with many clients / addresses. I am running a three node fully connected mesh
of dispatch routers with 1 attached clients all with two address messaging
at around 100 msg/sec.
In the logs I am seeing the following errors:
{{2018-05-29 14:31:05.145732 + ERROR (error) Invalid message: Insufficient
Data to Determine Tag}}
{{2018-05-29 14:31:05.145748 + ERROR (error) Invalid message: Can't
convert message field body}}
Which, in turn, lead to python errors like:
{{2018-05-29 14:31:05.145971 + ROUTER_MA (trace) RCVD: MAU(id=None pv=1
area=0 mobile_seq=0)}}
{{2018-05-29 14:31:05.146130 + ROUTER (error) Exception in control message
processing}}
{{ Traceback (most recent call last):}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/engine.py", line 157,
in handleControlMessage}}
{{ self.mobile_address_engine.handle_mau(msg, now)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/mobile.py", line 97,
in handle_mau}}
{{ node = self.node_tracker.router_node(msg.id)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/node.py", line 363,
in router_node}}
{{ return self.nodes[node_id]}}
{{ KeyError: None}}
{{2018-05-29 14:31:05.146175 + ROUTER (error) Control message error:
opcode=MAU body=None}}
I have tracked down the cause of the "Insufficient Data to Determine Tag"
message to the following: During the call to {{qd_parse}} of the {{MAU}}
message the {{qd_iterator_t}} reaches the end of the buffer list before it
should. Specifically the call to {{qd_iterator_advance}} here
[https://github.com/apache/qpid-dispatch/blob/master/src/parse.c#L151,] "fails;
to move forward a certain number of bytes (e.g. 31) even though the
{{iterator->view_pointer->remaining}} value has plenty of bytes left (e.g.
84802). The "fail" is because we reach the end of the buffer list before we
should (here
[https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323).]).
What I have not been able to figure out yet is why this happens because it is
not consistent. Many large MAU message are parsed correctly only sometimes not.
I am able to reproduce these errors every time I run my tests. There may be a
time component involved because the more logging I to the router code, the less
often the errors seem to occur.
was:
After DISPATCH-966 has been fixed I am still experiencing problems in a network
with many clients / addresses. I am running a three node fully connected mesh
of dispatch routers with 1 attached clients all with two address messaging
at around 100 msg/sec.
In the logs I am seeing the following errors:
{{2018-05-29 14:31:05.145732 + ERROR (error) Invalid message: Insufficient
Data to Determine Tag}}
{{2018-05-29 14:31:05.145748 + ERROR (error) Invalid message: Can't
convert message field body}}
Which, in turn, lead to python errors like:
{{2018-05-29 14:31:05.145971 + ROUTER_MA (trace) RCVD: MAU(id=None pv=1
area=0 mobile_seq=0)}}
{{ 2018-05-29 14:31:05.146130 + ROUTER (error) Exception in control message
processing}}
{{ Traceback (most recent call last):}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/engine.py", line 157,
in handleControlMessage}}
{{self.mobile_address_engine.handle_mau(msg, now)}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/mobile.py", line 97,
in handle_mau}}
{{node = self.node_tracker.router_node(msg.id)}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/node.py", line 363, in
router_node}}
{{return self.nodes[node_id]}}
{{ KeyError: None}}
{{ 2018-05-29 14:31:05.146175 + ROUTER (error) Control message error:
opcode=MAU body=None}}
I have tracked down the cause of the "Insufficient Data to Determine Tag"
message to the following: During the call to {{qd_parse}} of the {{MAU}}
message the {{qd_iterator_t}} reaches the end of the buffer list before it
should. Specifically the call to {{qd_iterator_advance}} here
[https://github.com/apache/qpid-dispatch/blob/master/src/parse.c#L151,] "fails;
to move forward a certain number of bytes (e.g. 31) even though the
{{iterator->view_pointer->remaining}} value has plenty of bytes left (e.g.
84802). The "fail" is because we reach the end of the buffer list before we
should (here
[https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323).]).
What I have not been able to figure out yet is why this happens because it is
not consistent. Many large MAU message are parsed correctly only sometimes not.
I am able to reproduce these errors every
[jira] [Updated] (DISPATCH-1019) Messaging instability in networks with many clients / addresses.
[
https://issues.apache.org/jira/browse/DISPATCH-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Meulemans updated DISPATCH-1019:
---
Description:
After DISPATCH-966 has been fixed I am still experiencing problems in a network
with many clients / addresses. I am running a three node fully connected mesh
of dispatch routers with 1 attached clients all with two address messaging
at around 100 msg/sec.
In the logs I am seeing the following errors:
{{2018-05-29 14:31:05.145732 + ERROR (error) Invalid message: Insufficient
Data to Determine Tag}}
{{2018-05-29 14:31:05.145748 + ERROR (error) Invalid message: Can't
convert message field body}}
Which, in turn, lead to python errors like:
{{2018-05-29 14:31:05.145971 + ROUTER_MA (trace) RCVD: MAU(id=None pv=1
area=0 mobile_seq=0)}}
{{ 2018-05-29 14:31:05.146130 + ROUTER (error) Exception in control message
processing}}
{{ Traceback (most recent call last):}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/engine.py", line 157,
in handleControlMessage}}
{{self.mobile_address_engine.handle_mau(msg, now)}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/mobile.py", line 97,
in handle_mau}}
{{node = self.node_tracker.router_node(msg.id)}}
{{File "/usr/lib/python2.7/qpid_dispatch_internal/router/node.py", line 363, in
router_node}}
{{return self.nodes[node_id]}}
{{ KeyError: None}}
{{ 2018-05-29 14:31:05.146175 + ROUTER (error) Control message error:
opcode=MAU body=None}}
I have tracked down the cause of the "Insufficient Data to Determine Tag"
message to the following: During the call to {{qd_parse}} of the {{MAU}}
message the {{qd_iterator_t}} reaches the end of the buffer list before it
should. Specifically the call to {{qd_iterator_advance}} here
[https://github.com/apache/qpid-dispatch/blob/master/src/parse.c#L151,] "fails;
to move forward a certain number of bytes (e.g. 31) even though the
{{iterator->view_pointer->remaining}} value has plenty of bytes left (e.g.
84802). The "fail" is because we reach the end of the buffer list before we
should (here
[https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323).]).
What I have not been able to figure out yet is why this happens because it is
not consistent. Many large MAU message are parsed correctly only sometimes not.
I am able to reproduce these errors every time I run my tests. There may be a
time component involved because the more logging I to the router code, the less
often the errors seem to occur.
was:
After DISPATCH-966 has been fixed I am still experiencing problems in a network
with many clients / addresses. I am running a three node fully connected mesh
of dispatch routers with 1 attached clients all with two address messaging
at around 100 msg/sec.
In the logs I am seeing the following errors:
{{2018-05-29 14:31:05.145732 + ERROR (error) Invalid message: Insufficient
Data to Determine Tag}}
{{2018-05-29 14:31:05.145748 + ERROR (error) Invalid message: Can't convert
message field body}}
Which, in turn, lead to python errors like:
{{2018-05-29 14:31:05.145971 + ROUTER_MA (trace) RCVD: MAU(id=None pv=1
area=0 mobile_seq=0)}}
{{2018-05-29 14:31:05.146130 + ROUTER (error) Exception in control message
processing}}
{{Traceback (most recent call last):}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/engine.py", line 157,
in handleControlMessage}}
{{ self.mobile_address_engine.handle_mau(msg, now)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/mobile.py", line 97,
in handle_mau}}
{{ node = self.node_tracker.router_node(msg.id)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/node.py", line 363,
in router_node}}
{{ return self.nodes[node_id]}}
{{KeyError: None}}
{{2018-05-29 14:31:05.146175 + ROUTER (error) Control message error:
opcode=MAU body=None}}
I have tracked down the cause of the "Insufficient Data to Determine Tag"
message to the following: During the call to {{qd_parse}} of the {{MAU}}
message the {{qd_iterator_t}} reaches the end of the buffer list before it
should. Specifically the call to {{qd_iterator_advance}} here
[https://github.com/apache/qpid-dispatch/blob/master/src/parse.c#L151,] "fails;
to move forward a certain number of bytes (e.g. 31) even though the
{{iterator->view_pointer->remaining}} value has plenty of bytes left (e.g.
84802). The "fail" is because we reach the end of the buffer list before we
should (here
[https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323).]).
What I have not been able to figure out yet is why this happens because it is
not consistent. Many large MAU message are parsed correctly only sometimes not.
I am able to reproduce these errors every
[jira] [Resolved] (DISPATCH-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1012. Resolution: Fixed > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.2.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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-1019) Messaging instability in networks with many clients / addresses.
Marcel Meulemans created DISPATCH-1019:
--
Summary: Messaging instability in networks with many clients /
addresses.
Key: DISPATCH-1019
URL: https://issues.apache.org/jira/browse/DISPATCH-1019
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 1.1.0
Reporter: Marcel Meulemans
After DISPATCH-966 has been fixed I am still experiencing problems in a network
with many clients / addresses. I am running a three node fully connected mesh
of dispatch routers with 1 attached clients all with two address messaging
at around 100 msg/sec.
In the logs I am seeing the following errors:
{{2018-05-29 14:31:05.145732 + ERROR (error) Invalid message: Insufficient
Data to Determine Tag}}
{{2018-05-29 14:31:05.145748 + ERROR (error) Invalid message: Can't convert
message field body}}
Which, in turn, lead to python errors like:
{{2018-05-29 14:31:05.145971 + ROUTER_MA (trace) RCVD: MAU(id=None pv=1
area=0 mobile_seq=0)}}
{{2018-05-29 14:31:05.146130 + ROUTER (error) Exception in control message
processing}}
{{Traceback (most recent call last):}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/engine.py", line 157,
in handleControlMessage}}
{{ self.mobile_address_engine.handle_mau(msg, now)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/mobile.py", line 97,
in handle_mau}}
{{ node = self.node_tracker.router_node(msg.id)}}
{{ File "/usr/lib/python2.7/qpid_dispatch_internal/router/node.py", line 363,
in router_node}}
{{ return self.nodes[node_id]}}
{{KeyError: None}}
{{2018-05-29 14:31:05.146175 + ROUTER (error) Control message error:
opcode=MAU body=None}}
I have tracked down the cause of the "Insufficient Data to Determine Tag"
message to the following: During the call to {{qd_parse}} of the {{MAU}}
message the {{qd_iterator_t}} reaches the end of the buffer list before it
should. Specifically the call to {{qd_iterator_advance}} here
[https://github.com/apache/qpid-dispatch/blob/master/src/parse.c#L151,] "fails;
to move forward a certain number of bytes (e.g. 31) even though the
{{iterator->view_pointer->remaining}} value has plenty of bytes left (e.g.
84802). The "fail" is because we reach the end of the buffer list before we
should (here
[https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L323).]).
What I have not been able to figure out yet is why this happens because it is
not consistent. Many large MAU message are parsed correctly only sometimes not.
I am able to reproduce these errors every time I run my tests. There may be a
time component involved because the more logging I to the router code, the less
often the errors seem to occur.
--
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-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494203#comment-16494203 ] ASF subversion and git services commented on DISPATCH-1012: --- Commit ab4421db6b1371e5ba902bc441ccc332352e7516 in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ab4421d ] DISPATCH-1012 - For anycast addresses, deliveries to an address that has no attached destinations shall be released by the router network and credit not replenished to the sender. Once a destination becomes reachable, the sender's credit shall be topped back up to the original capacity. > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.2.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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-941) Router is returning incorrect files from http get requests.
[ https://issues.apache.org/jira/browse/DISPATCH-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved DISPATCH-941. -- Resolution: Fixed Assignee: Alan Conway Fix Version/s: (was: Backlog) 1.1.0 > Router is returning incorrect files from http get requests. > --- > > Key: DISPATCH-941 > URL: https://issues.apache.org/jira/browse/DISPATCH-941 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.1 >Reporter: Ernest Allen >Assignee: Alan Conway >Priority: Major > Fix For: 1.1.0 > > Attachments: CaptureApache_angular.PNG, CaptureApache_angular.PNG, > CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, > CaptureDispatch_angular.PNG, CaptureDispatch_angular.PNG, > CaptureDispatch_woff2.PNG > > > When http requests are made from a Windows machine, the http response headers > appear to be mixed up or for a different request. For example, when the > browser requests the file OpenSans-Regular-webfont.woff2, the response has a > content-type of text/javascript and an incorrect content-length. Here is the > bad response: !CaptureDispatch_woff2.PNG! > When the same browser on the same machine requests the same file from Apache > tomcat, the response is correct: > !CaptureApache_woff2.PNG! > Another example: This time the request is for the javascript file angular.js. > Here is the bad response from the router: > !CaptureDispatch_angular.PNG! > > And here is the correct response from tomcat for the same file: > !CaptureApache_angular.PNG! > The incorrect content-types and content-lengths returned by the router lead > me to believe that the responses are getting mixed up. > Possibly important note: Which requests are mixed up varies each time I > reload the page. Sometimes files that failed on a previous page load will > come down just fine. It doesn't always happen on the same files. > This happens for all browsers I've tried on Windows. It does not happen for > any browser when the request comes from my linux box. > -- 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-941) Router is returning incorrect files from http get requests.
[ https://issues.apache.org/jira/browse/DISPATCH-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494008#comment-16494008 ] ASF subversion and git services commented on DISPATCH-941: -- Commit c728d7f41c78ccc8db127b87c11470a5b9bc8c82 in qpid-dispatch's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c728d7f ] DISPATCH-941: Router is returning incorrect files from http get Bug in http-libwebsockets code. A partial HTTP handler such as we have needs to call lws_callback_http_dummy() to fill in default HTTP behaviours. Without that the LWS library was not properly informed of termination of HTTP transactions causing confusion if a connection was re-used. > Router is returning incorrect files from http get requests. > --- > > Key: DISPATCH-941 > URL: https://issues.apache.org/jira/browse/DISPATCH-941 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.1 >Reporter: Ernest Allen >Priority: Major > Fix For: Backlog > > Attachments: CaptureApache_angular.PNG, CaptureApache_angular.PNG, > CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, > CaptureDispatch_angular.PNG, CaptureDispatch_angular.PNG, > CaptureDispatch_woff2.PNG > > > When http requests are made from a Windows machine, the http response headers > appear to be mixed up or for a different request. For example, when the > browser requests the file OpenSans-Regular-webfont.woff2, the response has a > content-type of text/javascript and an incorrect content-length. Here is the > bad response: !CaptureDispatch_woff2.PNG! > When the same browser on the same machine requests the same file from Apache > tomcat, the response is correct: > !CaptureApache_woff2.PNG! > Another example: This time the request is for the javascript file angular.js. > Here is the bad response from the router: > !CaptureDispatch_angular.PNG! > > And here is the correct response from tomcat for the same file: > !CaptureApache_angular.PNG! > The incorrect content-types and content-lengths returned by the router lead > me to believe that the responses are getting mixed up. > Possibly important note: Which requests are mixed up varies each time I > reload the page. Sometimes files that failed on a previous page load will > come down just fine. It doesn't always happen on the same files. > This happens for all browsers I've tried on Windows. It does not happen for > any browser when the request comes from my linux box. > -- 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-1683) support static library output
[ https://issues.apache.org/jira/browse/PROTON-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1683. - Resolution: Fixed Fix Version/s: proton-c-0.24.0 > support static library output > - > > Key: PROTON-1683 > URL: https://issues.apache.org/jira/browse/PROTON-1683 > Project: Qpid Proton > Issue Type: Improvement > Components: build > Environment: centos 6u5 >Reporter: WangYao >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > My company get used to link application using static library, will proton > support static library output? -- 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-1683) support static library output
[ https://issues.apache.org/jira/browse/PROTON-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493970#comment-16493970 ] ASF subversion and git services commented on PROTON-1683: - Commit a04a964de3925027ed63454fb8475e7a9a5b1ff5 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a04a964 ] PROTON-1683: [c,cpp] create static libraries `cmake -DBUILD_STATIC_LIBS=YES` builds static as well as shared C and C++ libraries. Requires static C or C++ runtime libraries to be available, they are optional on some platforms. E.g. on fedora 28: `sudo dnf install libstdc++-static` > support static library output > - > > Key: PROTON-1683 > URL: https://issues.apache.org/jira/browse/PROTON-1683 > Project: Qpid Proton > Issue Type: Improvement > Components: build > Environment: centos 6u5 >Reporter: WangYao >Assignee: Alan Conway >Priority: Major > > My company get used to link application using static library, will proton > support static library output? -- 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-921) Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved DISPATCH-921. -- Resolution: Fixed Closed as this issue is already part of a release as pointed out. Cloned to DISPATCH-1018 for further discussion > Install console dependencies with npm during make install > - > > Key: DISPATCH-921 > URL: https://issues.apache.org/jira/browse/DISPATCH-921 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.1.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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-1018) CLONE - Install console dependencies with npm during make install
Alan Conway created DISPATCH-1018: - Summary: CLONE - Install console dependencies with npm during make install Key: DISPATCH-1018 URL: https://issues.apache.org/jira/browse/DISPATCH-1018 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.0.0 Reporter: Alan Conway Assignee: Ernest Allen Fix For: 1.1.0 Attachments: 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch During a make install, the stand-alone console's dependencies should be installed using the command 'npm install' executed from the console's install directory. -- 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-963) Router crash during shutdown in system_tests_distribution
[
https://issues.apache.org/jira/browse/DISPATCH-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493936#comment-16493936
]
ASF GitHub Bot commented on DISPATCH-963:
-
Github user ganeshmurthy closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/292
> Router crash during shutdown in system_tests_distribution
> -
>
> Key: DISPATCH-963
> URL: https://issues.apache.org/jira/browse/DISPATCH-963
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Tests
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> The router crashes during shutdown in system_tests_distribution.py
> Here is the backtrace
>
> {noformat}
> (gdb) bt
> #0 0x7f361ca5ae40 in pn_ep_decref (endpoint=0x7f35f01c2dd0) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:447
> #1 0x7f361ca5b58b in pn_ep_decref (endpoint=) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:445
> #2 0x7f361ca5f588 in pni_transport_unbind_handles
> (handles=0x7f35f00764a0, reset_state=reset_state@entry=true) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:748
> #3 0x7f361ca5f666 in pni_transport_unbind_channels (channels=0x9d1ce0)
> at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:761
> #4 0x7f361ca5f777 in pn_transport_unbind (transport=0xa863d0) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:795
> #5 0x7f361ca5a63e in pn_connection_driver_release_connection
> (d=d@entry=0xa86248) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:81
> #6 0x7f361ca5a679 in pn_connection_driver_destroy (d=d@entry=0xa86248)
> at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:92
> #7 0x7f361c83a69c in pconnection_final_free (pc=0xa85ca0) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:827
> #8 0x7f361c83b3ac in pconnection_cleanup (pc=) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:843
> #9 0x7f361c83db37 in pconnection_forced_shutdown (pc=0xa85ca0) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:878
> #10 pn_proactor_free (p=0x916fd0) at
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:1815
> #11 0x7f361cce7bb5 in qd_server_free (qd_server=0x919190) at
> /home/gmurthy/opensource/qpid-dispatch/src/server.c:1176
> #12 0x7f361cca878e in qd_dispatch_free (qd=0x6164b0) at
> /home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:318
> #13 0x00401864 in main_process (config_path=0x7ffcb36d88e2 "B.conf",
> python_pkgdir=0x7ffcb36d88ec "/home/gmurthy/opensource/qpid-dispatch/python",
> fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
> #14 0x004022b0 in main (argc=5, argv=0x7ffcb36d8158) at
> /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:360
> (gdb){noformat}
>
> Running the test under valgrind, it seems that the pn_proactor_free is trying
> to free already freed link endpoint. Here are two outputs from valgrind
>
> {noformat}
> Process 3493 error: exit code 42, expected 0
> qdrouterd -c B.conf -I /home/gmurthy/opensource/qpid-dispatch/python
> /home/gmurthy/opensource/qpid-dispatch/build/system_test.dir/system_tests_distribution/DistributionTests/setUpClass/B-2.cmd
>
> ==3493== Invalid write of size 8
> ==3493== at 0x50E82B0: pn_link_unbound (engine.c:1202)
> ==3493== by 0x50EB5D0: pni_transport_unbind_handles (transport.c:746)
> ==3493== by 0x50EB665: pni_transport_unbind_channels (transport.c:761)
> ==3493== by 0x50EB776: pn_transport_unbind (transport.c:795)
> ==3493== by 0x50E663D: pn_connection_driver_release_connection
> (connection_driver.c:81)
> ==3493== by 0x50E6678: pn_connection_driver_destroy
> (connection_driver.c:92)
> ==3493== by 0x530A69B: pconnection_final_free (epoll.c:827)
> ==3493== by 0x530DB36: pconnection_forced_shutdown (epoll.c:878)
> ==3493== by 0x530DB36: pn_proactor_free (epoll.c:1815)
> ==3493== by 0x4EA5BB4: qd_server_free (server.c:1176)
> ==3493== by 0x4E6678D: qd_dispatch_free (dispatch.c:318)
> ==3493== by 0x401863: main_process (main.c:116)
> ==3493== by 0x4022AF: main (main.c:360)
> ==3493== Address 0x15c06188 is 376 bytes inside a block of size 488 free'd
> ==3493== at 0x4C2DD18: free (vg_replace_malloc.c:530)
> ==3493== by 0x50DD938: pn_class_decref (object.c:101)
> ==3493== by 0x50EA03F: pn_event_finalize (event.c:226)
> ==3493== by 0x50EA03F: pn_event_finalize_cast (event.c:271)
> ==3493== by
[GitHub] qpid-dispatch pull request #292: DISPATCH-963 - Added test name to creation ...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/292 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-921) Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493866#comment-16493866 ] Robbie Gemmell commented on DISPATCH-921: - A couple of thoughts: A) This JIRA is part of the 1.1.0 RC that already has sufficient votes and time-open to pass. The JIRA shouldnt be getting more changes made on it if that release goes out, use another (e.g create a new one as Ernie has). B) All the chat on how to install the console during the dispatch install perhaps overlooks another area to think on: should the console still be part of the Dispatch install, or would it suit its own release? > Install console dependencies with npm during make install > - > > Key: DISPATCH-921 > URL: https://issues.apache.org/jira/browse/DISPATCH-921 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.1.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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-921) Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493823#comment-16493823 ] Ernest Allen commented on DISPATCH-921: --- This could be a good solution until DISPATCH-1017 is implemented. That Jira would install the 3rd party libraries at router build time, but it would also run other utilities on the source files to compile/aggregate/minify/lint. Only a few larger files would be copied to the console's install dir and not all of the files under node_modules. > Install console dependencies with npm during make install > - > > Key: DISPATCH-921 > URL: https://issues.apache.org/jira/browse/DISPATCH-921 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.1.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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-1017) Use a javascript build system for the console
Ernest Allen created DISPATCH-1017: -- Summary: Use a javascript build system for the console Key: DISPATCH-1017 URL: https://issues.apache.org/jira/browse/DISPATCH-1017 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen It's time to use a javascript build system such as gulp for the console. A build system would run during the router's 'make build' and do the following: * npm install all 3rd party libraries * compile any typescript and scss files to .js and .css respectively * package all .css files (3rd party and homegrown) into a single .css file * package all .js files (again 3rd party and homegrown) into a single .js file * minify the css and js files * run a javascript linter After the gulp build, only a few files would need to be copied to the console install directory. To ensure the downstream package builds are consistent, the package_lock.json file should specify which version of the 3rd party libraries to use. -- 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-1008) Router should preserve original connection information when attempting to make failover connections
[
https://issues.apache.org/jira/browse/DISPATCH-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493724#comment-16493724
]
ASF GitHub Bot commented on DISPATCH-1008:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/310
DISPATCH-1008 - Original connection information is preserved in the f…
…ailover list and a connection is attempted via round robin when the router
fails over
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1008
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/310.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #310
commit 48c36134e406dfddc396a9f624f61b9e8781fa13
Author: Ganesh Murthy
Date: 2018-05-25T19:07:44Z
DISPATCH-1008 - Original connection information is preserved in the
failover list and a connection is attempted via round robin when the router
fails over
> Router should preserve original connection information when attempting to
> make failover connections
> ---
>
> Key: DISPATCH-1008
> URL: https://issues.apache.org/jira/browse/DISPATCH-1008
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: broker-slave.xml, broker.xml, qdrouterd-failover.conf
>
>
> # Start artemis master and slave brokers and the router with the attached
> config files.
> # Notice that the router receives an open frame from the master broker with
> the following failover information
> #
> {noformat}
> 2018-05-22 22:11:11.830106 -0230 SERVER (trace) [1]:0 <- @open(16)
> [container-id="localhost", max-frame-size=4294967295, channel-max=65535,
> idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis",
> :"failover-server-list"=[{:hostname="0.0.0.8", :scheme="amqp", :port=61617,
> :"network-host"="0.0.0.0"}]"}]{noformat}
>
> # Now, kill the master broker and notice that the router correctly fails
> over to the slave broker. But the slave broker does not provide any failover
> information in its open frame and hence the router erases its original master
> broker connection information
> # When the master broker is now restarted and the slave broker is killed,
> the router attempts to repeatedly connect only to the slave broker but never
> attempts a connection to the master broker.
> # If the router did not erase its failover list but preserved the original
> master connection information, it would have connected the master broker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #310: DISPATCH-1008 - Original connection informa...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/310 DISPATCH-1008 - Original connection information is preserved in the f⦠â¦ailover list and a connection is attempted via round robin when the router fails over You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1008 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/310.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #310 commit 48c36134e406dfddc396a9f624f61b9e8781fa13 Author: Ganesh Murthy Date: 2018-05-25T19:07:44Z DISPATCH-1008 - Original connection information is preserved in the failover list and a connection is attempted via round robin when the router fails over --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1849) [c] server behaves incorrectly on duplicate link attach
[
https://issues.apache.org/jira/browse/PROTON-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway closed PROTON-1849.
---
Resolution: Duplicate
> [c] server behaves incorrectly on duplicate link attach
> ---
>
> Key: PROTON-1849
> URL: https://issues.apache.org/jira/browse/PROTON-1849
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.24.0
>
>
> --The fix for
> PROTON-1832: [c] reject duplicate link attach with connection error.
> Is incorrect. It raises a transport eror on duplicate link names. That is
> better than crashing but the AMQP spec says:
>
> {quote}2.6.1 Naming A Link
> [snip]
> A link's name uniquely identifies the link from the container of the source
> to the container of the target node, i.e., if the container of the source
> node is A, and the container of the target node is B, the link can be
> globally identified by the (ordered) tuple _(A,B,)_. Consequently, a
> link can only be active in one connection at a time. If an attempt is made to
> attach the link subsequently when it is not suspended, then the link can be
> 'stolen', i.e., the second attach succeeds and the first attach MUST then be
> closed with a link error of
> [stolen|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#choice-link-error-stolen].
> This behavior ensures that in the event of a connection failure occurring
> and being noticed by one party, that re-establishment has the desired effect.
> {quote}
> The spec is anticipating duplicate names being used on *different*
> connections during reconnect but we should treat duplicates on the same
> connection the same way. In particular proton should dispatch the events to
> close the stolen link *before* the events that open the new link.
> On the client side, a duplicate link attach will cause the original link to
> be closed with a STOLEN error, then open the new link. The events and
> protocol frames will show the close/STOLEN first, then the open.
> This is more consistent with the spec, and more forgiving than closing the
> connection with an error. It means intermediaries that just forward link
> traffic will do the right thing automatically on an upstream reconnect (close
> and re-open the downstream link) even if they don't locally check for link
> name duplication.
--
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-941) Router is returning incorrect files from http get requests.
[ https://issues.apache.org/jira/browse/DISPATCH-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493669#comment-16493669 ] Alan Conway commented on DISPATCH-941: -- I have raised an issue with libwebsockets: [https://github.com/warmcat/libwebsockets/issues/1296] The console works with libwebsockets.so.10, it stops working with libwebsockets.so.11 and continues not to work with .so.12 Until we resolve the problem I suggest we make dispatch link explicitly with libwebsockets .so.10 - I don't know the RPM magic offhand but I'm pretty sure that is possible. [~eallen] has confirmed that even on latest fedora 28 with the latest libwebsockets installed, linking with the older .so works. > Router is returning incorrect files from http get requests. > --- > > Key: DISPATCH-941 > URL: https://issues.apache.org/jira/browse/DISPATCH-941 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.1 >Reporter: Ernest Allen >Priority: Major > Fix For: Backlog > > Attachments: CaptureApache_angular.PNG, CaptureApache_angular.PNG, > CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, > CaptureDispatch_angular.PNG, CaptureDispatch_angular.PNG, > CaptureDispatch_woff2.PNG > > > When http requests are made from a Windows machine, the http response headers > appear to be mixed up or for a different request. For example, when the > browser requests the file OpenSans-Regular-webfont.woff2, the response has a > content-type of text/javascript and an incorrect content-length. Here is the > bad response: !CaptureDispatch_woff2.PNG! > When the same browser on the same machine requests the same file from Apache > tomcat, the response is correct: > !CaptureApache_woff2.PNG! > Another example: This time the request is for the javascript file angular.js. > Here is the bad response from the router: > !CaptureDispatch_angular.PNG! > > And here is the correct response from tomcat for the same file: > !CaptureApache_angular.PNG! > The incorrect content-types and content-lengths returned by the router lead > me to believe that the responses are getting mixed up. > Possibly important note: Which requests are mixed up varies each time I > reload the page. Sometimes files that failed on a previous page load will > come down just fine. It doesn't always happen on the same files. > This happens for all browsers I've tried on Windows. It does not happen for > any browser when the request comes from my linux box. > -- 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] (DISPATCH-921) Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened DISPATCH-921: -- I don't think breaking the upstream installer for the convenience of downstream packaging is the right solution. The attached patch puts the NPM files back into the installer, but can easily be disabled by packagers with `cmake -DCONSOLE_NPM_INSTALL=NO`. However when we do make a downstream package will will need to package a predictable version of the console dependencies so I don't think we will want to disable the NPM install. Rather we will want to specify exact NPM versions in the repository an allow those predictable, reproducible, traceable versions to be installed and packaged with the rest of the code. > Install console dependencies with npm during make install > - > > Key: DISPATCH-921 > URL: https://issues.apache.org/jira/browse/DISPATCH-921 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.1.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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-921) Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-921: - Attachment: 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > Install console dependencies with npm during make install > - > > Key: DISPATCH-921 > URL: https://issues.apache.org/jira/browse/DISPATCH-921 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.1.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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-1016) Consolidate console style sheets to improve load time
[ https://issues.apache.org/jira/browse/DISPATCH-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1016. Resolution: Fixed Fix Version/s: 1.2.0 > Consolidate console style sheets to improve load time > - > > Key: DISPATCH-1016 > URL: https://issues.apache.org/jira/browse/DISPATCH-1016 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > Rather than load 3 separate internal style sheets for the console: > * plugin.css > * dispatchpf.css > * dispatch.css > consolidate them into a single style sheet named dispatch.css. > Note: The style sheets for the 3rd party libraries will still be loaded > separately. > -- 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-1016) Consolidate console style sheets to improve load time
[ https://issues.apache.org/jira/browse/DISPATCH-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493420#comment-16493420 ] ASF subversion and git services commented on DISPATCH-1016: --- Commit 5220221f64ba25d6e089ae77ff4b7f4606de884a in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5220221 ] DISPATCH-1016 Consolidate console style sheets > Consolidate console style sheets to improve load time > - > > Key: DISPATCH-1016 > URL: https://issues.apache.org/jira/browse/DISPATCH-1016 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > Rather than load 3 separate internal style sheets for the console: > * plugin.css > * dispatchpf.css > * dispatch.css > consolidate them into a single style sheet named dispatch.css. > Note: The style sheets for the 3rd party libraries will still be loaded > separately. > -- 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-1016) Consolidate console style sheets to improve load time
Ernest Allen created DISPATCH-1016: -- Summary: Consolidate console style sheets to improve load time Key: DISPATCH-1016 URL: https://issues.apache.org/jira/browse/DISPATCH-1016 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen Rather than load 3 separate internal style sheets for the console: * plugin.css * dispatchpf.css * dispatch.css consolidate them into a single style sheet named dispatch.css. Note: The style sheets for the 3rd party libraries will still be loaded separately. -- 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-1015) Improve visualization of connection and link info on console's topology page.
Ernest Allen created DISPATCH-1015: -- Summary: Improve visualization of connection and link info on console's topology page. Key: DISPATCH-1015 URL: https://issues.apache.org/jira/browse/DISPATCH-1015 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen Change the way connection and link info is presented on the topology page. Changes should include: * Remove the sliding panel on the left * When page is narrow (mobile phone size) ** hide legend ** show page menu icon in banner ** when page menu icon is clicked popup legend * When mouseover a router, popup tooltip that shows ** Full router name ** list of listener ports ** router version * When mouseover a client/service/broker, popup tooltip that shows ** type (sender/receiver/service/console/broker) ** host ** connection properties if any ** security, authentication, tenant * When mouseover a line from routers to clients, popup tooltip that shows ** same info as mouseover the client circle ** list of links *** sorted descending by link statistics *** up to 10 links *** show link address, direction, statistics * When mouseover a line from router to router, popup tooltip that shows ** security, authentication, tenant ** same list of links as mouseover line to client (without address) * When click on line or router or client ** show modal dialog with same info as mouseover *** for list of links, show up to 20 links with ability to filter -- 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
[ANNOUNCE] Apache Qpid Proton 0.23.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Proton 0.23.0. Apache Qpid Proton is a messaging library for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used in a wide range of messaging applications including brokers, clients, routers, bridges, proxies, and more. The release is available now from our website: http://qpid.apache.org/download.html Release notes can be found at: http://qpid.apache.org/releases/qpid-proton-0.23.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1014) Visualize link congestion on topology page
[ https://issues.apache.org/jira/browse/DISPATCH-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493301#comment-16493301 ] ASF subversion and git services commented on DISPATCH-1014: --- Commit e54c632bca5f4cf0f54728f2f3bf1851e664caf1 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e54c632 ] DISPATCH-1014 Add link utilization visualization to console's topology page > Visualize link congestion on topology page > -- > > Key: DISPATCH-1014 > URL: https://issues.apache.org/jira/browse/DISPATCH-1014 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > Implement new visualization on topology page with the following features: > * controlled by radio button in legend. state should be saved > * change color of lines connecting routers and clients to indicate link > utilization > * colors should range from gray for idle, green for used, red for busy > * change arrow color on line to match the line's color > * mouseover line should popup info on links that contains address, > direction, undelivered, unsettled, rejected, released, modified > * popup should be dynamically updated while visible > * popup should be sorted by the sum of the link statistics and show up to 10 > links > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1014) Visualize link congestion on topology page
Ernest Allen created DISPATCH-1014: -- Summary: Visualize link congestion on topology page Key: DISPATCH-1014 URL: https://issues.apache.org/jira/browse/DISPATCH-1014 Project: Qpid Dispatch Issue Type: New Feature Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen Implement new visualization on topology page with the following features: * controlled by radio button in legend. state should be saved * change color of lines connecting routers and clients to indicate link utilization * colors should range from gray for idle, green for used, red for busy * change arrow color on line to match the line's color * mouseover line should popup info on links that contains address, direction, undelivered, unsettled, rejected, released, modified * popup should be dynamically updated while visible * popup should be sorted by the sum of the link statistics and show up to 10 links -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1002) Animate message flow on the console's topology page.
[ https://issues.apache.org/jira/browse/DISPATCH-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1002. Resolution: Implemented Fix Version/s: 1.2.0 > Animate message flow on the console's topology page. > > > Key: DISPATCH-1002 > URL: https://issues.apache.org/jira/browse/DISPATCH-1002 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.2.0 > > > Create an option on the topology page to show message flow through the > network with the following features: > * Checkbox to show/hide message flow. > * Save show/hide state to local storage > * Animate dots between the ingress client and egress client, through the > network > * In the legend, show addresses that are active > ** with a unique color per address that matches the color of the dots in the > animation for that address > ** Add a checkbox per address to filter the animations > ** When mouse rolls over an address in the legend, fade other addresses > * Show relative rates of message flow by slightly varying the speed of the > animation > -- 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-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20
[
https://issues.apache.org/jira/browse/PROTON-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493275#comment-16493275
]
Robbie Gemmell commented on PROTON-1809:
Added PROTON-1827 as a sub-task since its related test fix commit should have
been directed against this issue.
> [python, ruby] Unable to receive messages when max-frame-size is set to more
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
> def on_session_init(self, event):
> event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size
> is 4294967295). I'm not really sure if that is expected. This may be
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in
> on_session_init is really too late. But given that it is too late to set the
> max-frame-size, I would expect it won't have any effect on the client.
>
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby]
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b -c --log-msgs dict
> --conn-max-frame-size 1048577}}
> Receiver is stuck.
--
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-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20
[
https://issues.apache.org/jira/browse/PROTON-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-1809.
--
Resolution: Fixed
> [python, ruby] Unable to receive messages when max-frame-size is set to more
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
> def on_session_init(self, event):
> event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size
> is 4294967295). I'm not really sure if that is expected. This may be
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in
> on_session_init is really too late. But given that it is too late to set the
> max-frame-size, I would expect it won't have any effect on the client.
>
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby]
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b -c --log-msgs dict
> --conn-max-frame-size 1048577}}
> Receiver is stuck.
--
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-1827) [c test] c-connection-driver-tests fail on windows
[
https://issues.apache.org/jira/browse/PROTON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-1827.
--
Resolution: Fixed
Converted to a sub-tax of PROTON-1809 (where Alan's related commit should have
gone) and removing fix-version as its conveyed by the parent.
> [c test] c-connection-driver-tests fail on windows
> --
>
> Key: PROTON-1827
> URL: https://issues.apache.org/jira/browse/PROTON-1827
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: proton-c
>Affects Versions: proton-c-0.23.0
>Reporter: Chuck Rolke
>Priority: Major
>
> A new self test related to PROTON-1809 fails hard.
> {{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session
> capacity 1234 is less than frame size 12345' not in 'session capacity 1234 is
> less than frame size 140707423596601 (connection aborted)'
> [test_session_flow_control()]}}
> {{ 10: FAIL: test_session_flow_control() (1 errors)}}
> {{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
> The large frame size number varies from run to run but is always in the
> region of 10^14.
--
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-1827) [c test] c-connection-driver-tests fail on windows
[
https://issues.apache.org/jira/browse/PROTON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1827:
---
Fix Version/s: (was: proton-c-0.23.0)
> [c test] c-connection-driver-tests fail on windows
> --
>
> Key: PROTON-1827
> URL: https://issues.apache.org/jira/browse/PROTON-1827
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: proton-c
>Affects Versions: proton-c-0.23.0
>Reporter: Chuck Rolke
>Priority: Major
>
> A new self test related to PROTON-1809 fails hard.
> {{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session
> capacity 1234 is less than frame size 12345' not in 'session capacity 1234 is
> less than frame size 140707423596601 (connection aborted)'
> [test_session_flow_control()]}}
> {{ 10: FAIL: test_session_flow_control() (1 errors)}}
> {{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
> The large frame size number varies from run to run but is always in the
> region of 10^14.
--
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-1827) [c test] c-connection-driver-tests fail on windows
[
https://issues.apache.org/jira/browse/PROTON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1827:
---
Issue Type: Sub-task (was: Bug)
Parent: PROTON-1809
> [c test] c-connection-driver-tests fail on windows
> --
>
> Key: PROTON-1827
> URL: https://issues.apache.org/jira/browse/PROTON-1827
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: proton-c
>Affects Versions: proton-c-0.23.0
>Reporter: Chuck Rolke
>Priority: Major
>
> A new self test related to PROTON-1809 fails hard.
> {{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session
> capacity 1234 is less than frame size 12345' not in 'session capacity 1234 is
> less than frame size 140707423596601 (connection aborted)'
> [test_session_flow_control()]}}
> {{ 10: FAIL: test_session_flow_control() (1 errors)}}
> {{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
> The large frame size number varies from run to run but is always in the
> region of 10^14.
--
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-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20
[
https://issues.apache.org/jira/browse/PROTON-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened PROTON-1809:
> [python, ruby] Unable to receive messages when max-frame-size is set to more
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
> def on_session_init(self, event):
> event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size
> is 4294967295). I'm not really sure if that is expected. This may be
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in
> on_session_init is really too late. But given that it is too late to set the
> max-frame-size, I would expect it won't have any effect on the client.
>
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby]
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b -c --log-msgs dict
> --conn-max-frame-size 1048577}}
> Receiver is stuck.
--
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-1827) [c test] c-connection-driver-tests fail on windows
[
https://issues.apache.org/jira/browse/PROTON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened PROTON-1827:
> [c test] c-connection-driver-tests fail on windows
> --
>
> Key: PROTON-1827
> URL: https://issues.apache.org/jira/browse/PROTON-1827
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.23.0
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> A new self test related to PROTON-1809 fails hard.
> {{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session
> capacity 1234 is less than frame size 12345' not in 'session capacity 1234 is
> less than frame size 140707423596601 (connection aborted)'
> [test_session_flow_control()]}}
> {{ 10: FAIL: test_session_flow_control() (1 errors)}}
> {{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
> The large frame size number varies from run to run but is always in the
> region of 10^14.
--
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
