[jira] [Commented] (PROTON-1488) Making Python server example more configurable
[ https://issues.apache.org/jira/browse/PROTON-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020817#comment-16020817 ] Paolo Patierno commented on PROTON-1488: Totally agree ! I have updated my PR in this direction. > Making Python server example more configurable > -- > > Key: PROTON-1488 > URL: https://issues.apache.org/jira/browse/PROTON-1488 > Project: Qpid Proton > Issue Type: Improvement > Components: examples >Reporter: Paolo Patierno >Priority: Trivial > > Hi, > it should be good having the Python server.py example more configurable from > the command line in order to specify the URL and the address. > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1488) Making Python server example more configurable
Paolo Patierno created PROTON-1488: -- Summary: Making Python server example more configurable Key: PROTON-1488 URL: https://issues.apache.org/jira/browse/PROTON-1488 Project: Qpid Proton Issue Type: Improvement Components: examples Reporter: Paolo Patierno Priority: Trivial Hi, it should be good having the Python server.py example more configurable from the command line in order to specify the URL and the address. Thanks, Paolo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-506: Comment: was deleted (was: I'm re-opening it because after the fix the router sends the detach with closed=false, this is what I see : [0x1f0bc80]:0 -> @detach(22) [handle=0, closed=false, error=@error(29) [condition=:"qd:routed-link-lost", description="Connectivity to the peer container was lost"]] ) > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno >Assignee: Ted Ross > Fix For: 0.8.0 > > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno closed DISPATCH-506. --- Resolution: Fixed Sorry for re-opening it. The close=false is deliberate after the discussion. > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno >Assignee: Ted Ross > Fix For: 0.8.0 > > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno reopened DISPATCH-506: - I'm re-opening it because after the fix the router sends the detach with closed=false, this is what I see : [0x1f0bc80]:0 -> @detach(22) [handle=0, closed=false, error=@error(29) [condition=:"qd:routed-link-lost", description="Connectivity to the peer container was lost"]] > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno >Assignee: Ted Ross > Fix For: 0.8.0 > > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-735) Crash on startup parsing JSON conf file with "address" entity
[
https://issues.apache.org/jira/browse/DISPATCH-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-735:
Description:
Hi,
using a router configuration file in the JSON format with something like this :
{noformat}
["address", {
"prefix": "telemetry/",
"distribution": "multicast"
}],
["address", {
"prefix": "event/",
"distribution": "multicast"
}],
{noformat}
the router crashes on startup with following error :
[root@512788e6bda1 /]# qdrouterd -c /etc/hono/qdrouter/qdrouterd.json
Fri Mar 31 08:51:48 2017 ERROR (error) Python: Exception: Cannot load
configuration file /etc/hono/qdrouter/qdrouterd.json: No such entity type
'org.apache.qpid.dispatch.address'
Fri Mar 31 08:51:48 2017 ERROR (error) Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 128, in configure_dispatch
config = Config(filename)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 41, in __init__
self.load(filename, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 98, in load
self.load(f, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 106, in load
self.schema.validate_all(entities)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 584, in validate_all
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 555, in validate_entity
entity_type = self.entity_type(attributes['type'])
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 541, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 537, in _lookup
raise ValidationError(message % name)
Exception: Cannot load configuration file /etc/hono/qdrouter/qdrouterd.json: No
such entity type 'org.apache.qpid.dispatch.address'
It doesn't happen using the deprecated "fixedAddress" entity.
was:
Hi,
using a router configuration file in the JSON format with something like this :
["address", {
"prefix": "telemetry/",
"distribution": "multicast"
}],
["address", {
"prefix": "event/",
"distribution": "multicast"
}],
the router crashes on startup with following error :
[root@512788e6bda1 /]# qdrouterd -c /etc/hono/qdrouter/qdrouterd.json
Fri Mar 31 08:51:48 2017 ERROR (error) Python: Exception: Cannot load
configuration file /etc/hono/qdrouter/qdrouterd.json: No such entity type
'org.apache.qpid.dispatch.address'
Fri Mar 31 08:51:48 2017 ERROR (error) Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 128, in configure_dispatch
config = Config(filename)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 41, in __init__
self.load(filename, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 98, in load
self.load(f, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 106, in load
self.schema.validate_all(entities)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 584, in validate_all
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 555, in validate_entity
entity_type = self.entity_type(attributes['type'])
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 541, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 537, in _lookup
raise ValidationError(message % name)
Exception: Cannot load configuration file /etc/hono/qdrouter/qdrouterd.json: No
such entity type 'org.apache.qpid.dispatch.address'
It doesn't happen using the deprecated "fixedAddress" entity.
> Crash on startup parsing JSON conf file with "address" entity
> -
>
> Key: DISPATCH-735
> URL: https://issues.apache.org/jira/browse/DISPATCH-735
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Paolo Patierno
>
> Hi,
> using a router configuration file in the JSON format with something like this
> :
> {noformat}
> ["address", {
> "prefix": "telemetry/",
> "distribution": "multicast"
> }],
> ["address", {
> "prefix": "event/",
> "distribution": "multicast"
> }]
[jira] [Created] (DISPATCH-735) Crash on startup parsing JSON conf file with "address" entity
Paolo Patierno created DISPATCH-735:
---
Summary: Crash on startup parsing JSON conf file with "address"
entity
Key: DISPATCH-735
URL: https://issues.apache.org/jira/browse/DISPATCH-735
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Paolo Patierno
Hi,
using a router configuration file in the JSON format with something like this :
["address", {
"prefix": "telemetry/",
"distribution": "multicast"
}],
["address", {
"prefix": "event/",
"distribution": "multicast"
}],
the router crashes on startup with following error :
[root@512788e6bda1 /]# qdrouterd -c /etc/hono/qdrouter/qdrouterd.json
Fri Mar 31 08:51:48 2017 ERROR (error) Python: Exception: Cannot load
configuration file /etc/hono/qdrouter/qdrouterd.json: No such entity type
'org.apache.qpid.dispatch.address'
Fri Mar 31 08:51:48 2017 ERROR (error) Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 128, in configure_dispatch
config = Config(filename)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 41, in __init__
self.load(filename, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 98, in load
self.load(f, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 106, in load
self.schema.validate_all(entities)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 584, in validate_all
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 555, in validate_entity
entity_type = self.entity_type(attributes['type'])
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 541, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 537, in _lookup
raise ValidationError(message % name)
Exception: Cannot load configuration file /etc/hono/qdrouter/qdrouterd.json: No
such entity type 'org.apache.qpid.dispatch.address'
It doesn't happen using the deprecated "fixedAddress" entity.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-630) Detecting connections with the same container-id
[ https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853731#comment-15853731 ] Paolo Patierno commented on DISPATCH-630: - Should the server provide even the "terminate-existing-connection-for-container" capability if it supports that ? I mean. The server could support "sole-connection" but only with the JMS behavior (which we can consider as default, so the second connection is denied) and in this case it MUST provide the "sole-connection-for-container" capability in its open frame. If it supports the MQTT-like behaviour, it MUST provide something like "terminate-existing-connection-for-container" as well. Or your idea is that if the server provides only the "sole-connection-for-container" it will support both behaviours ? How much "grained" we want to be on that ? Btw ... I agree with the proposal ;) > Detecting connections with the same container-id > > > Key: DISPATCH-630 > URL: https://issues.apache.org/jira/browse/DISPATCH-630 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Paolo Patierno >Priority: Minor > > Using the router in the EnMasse project and looking into the MQTT > specification we have the following problem on the current EnMasse > implemetation. > The MQTT specification says the following ... > Let's imagine that a client is connected to the broker with client id "1234" > and that another client tries to connect with same client id. The broker will > shut down the connection with first client opening the new one. > Now with our MQTT support, the MQTT gateway can run as multiple instances > (multiple pods) so this check can't be executed by the gateway locally > because a client "1234" could connect to MQTT GW-1 and another client (always > "1234") could connect to the MQTT GW-2 and the gateways don't know about each > other. The common point they have is the router network inside EnMasse and > the fact that for each MQTT client a new AMQP connection is created on the > other side attaching a link with this name : $mqtt.to. > The following idea came ... > If during the connection we use a container-id that is equals to the > client-id, could the router have a feature for detecting connections with > same container-id and providing a way to close the previous ones ? > It should be an information shared (and cached ?) by routers in their > inter-router protocol. > If not at connection level, maybe at link attachment level ? (when two > clients attach to the same $mqtt.to. link) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-630) Detecting connections with the same container-id
Paolo Patierno created DISPATCH-630: --- Summary: Detecting connections with the same container-id Key: DISPATCH-630 URL: https://issues.apache.org/jira/browse/DISPATCH-630 Project: Qpid Dispatch Issue Type: Improvement Reporter: Paolo Patierno Priority: Minor Using the router in the EnMasse project and looking into the MQTT specification we have the following problem on the current EnMasse implemetation. The MQTT specification says the following ... Let's imagine that a client is connected to the broker with client id "1234" and that another client tries to connect with same client id. The broker will shut down the connection with first client opening the new one. Now with our MQTT support, the MQTT gateway can run as multiple instances (multiple pods) so this check can't be executed by the gateway locally because a client "1234" could connect to MQTT GW-1 and another client (always "1234") could connect to the MQTT GW-2 and the gateways don't know about each other. The common point they have is the router network inside EnMasse and the fact that for each MQTT client a new AMQP connection is created on the other side attaching a link with this name : $mqtt.to. The following idea came ... If during the connection we use a container-id that is equals to the client-id, could the router have a feature for detecting connections with same container-id and providing a way to close the previous ones ? It should be an information shared (and cached ?) by routers in their inter-router protocol. If not at connection level, maybe at link attachment level ? (when two clients attach to the same $mqtt.to. link) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-599) Link routing : messages is not transferred if sender detach link immediately
Paolo Patierno created DISPATCH-599: --- Summary: Link routing : messages is not transferred if sender detach link immediately Key: DISPATCH-599 URL: https://issues.apache.org/jira/browse/DISPATCH-599 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.8.0 Reporter: Paolo Patierno Hi, using link routing, if the sender sends a message and detach the link immediately after that, the message isn't transferred to the receiver (just dropped by the router ?). Following what I see from log : [0x7fd30803e4c0]:0 <- @transfer(20) [handle=3, delivery-id=1, delivery-tag=b"1", message-format=0] (66) "\x00Sp\xc0\x06\x05B@@@C\x00Sr\xc1\x15\x04\xa3\x05x-qosT\x00\xa3\x08x-retainB\x00Ss\xc0\x0e\x03T\xff@\xa1\x08my_topic\x00Su\xa0\x05Hello" [0x7fd30803e4c0]:0 <- @detach(22) [handle=3, closed=true] [0x7fd30803e4c0]:0 <- @close(24) [] [0x7fd30803e4c0]: <- EOS [0x7fd30803e4c0]:0 -> @close(24) [] [0x7fd308021780]:1 -> @detach(22) [handle=0, closed=true] [0x7fd30803e4c0]: -> EOS It doesn't happen with message routing. Thanks, Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721485#comment-15721485 ] Paolo Patierno commented on DISPATCH-583: - I have just built the router using the bits from the Ganesh fork with the above update (not yet merged in the original repo). Against my unit tests related to the MQTT frontend, the router doesn't crash anymore and I can see a clean closing procedure of the links and connections from the MQTT frontend. So ... it seems that the Ganesh update is working fine. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15714547#comment-15714547 ] Paolo Patierno commented on DISPATCH-583: - Currently I can't finish any of my unit tests ... the qdrouter goes always in segmentation fault. I'm using the latest bits from github (also applying the patch for the message annotations that seems to be not present on upstream yet). Coming back to the qdrouterd I was using few days ago so 0.7.0 rc2, the segmentation fault is more random than today but at least I can run my unit tests. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712175#comment-15712175 ] Paolo Patierno edited comment on DISPATCH-583 at 12/1/16 2:53 PM: -- Ok ... I'm quite sure that the segmentation fault is related to connection suddenly closed. I have a systematic way for crashing, using my mqtt-frontend project and running this specific test : mvn -Dtest=PublishTest#publishQoS0toMqtt test I have to fix synchronization in my unit test to avoid this suddenly connection close but now we have more info to discover why the router crash. was (Author: ppatierno): Ok ... I'm quite sure that the segmentation fault is related to connection suddenly closed. I have a systematic way for crashing, using my mqtt-frontend project and running this specific test : mvn -Dtest=PublishTest#publishQoS0toMqtt test I have to fix synchronization in my unit test to avoid this seddenly connection close but now we have more info to discover why the router crash. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712175#comment-15712175 ] Paolo Patierno commented on DISPATCH-583: - Ok ... I'm quite sure that the segmentation fault is related to connection suddenly closed. I have a systematic way for crashing, using my mqtt-frontend project and running this specific test : mvn -Dtest=PublishTest#publishQoS0toMqtt test I have to fix synchronization in my unit test to avoid this seddenly connection close but now we have more info to discover why the router crash. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[
https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712141#comment-15712141
]
Paolo Patierno commented on DISPATCH-583:
-
I have just had a segmentation fault with latest compiled bits (few minutes
ago) :
{noformat}
[0x7f42b402fdc0]:0 <- @detach(22) [handle=1, closed=true]
[0x7f42bc0247c0]:0 -> @detach(22) [handle=0, closed=true]
[0x7f42b402fdc0]:0 <- @detach(22) [handle=2, closed=true]
[0x7f42b402fdc0]:0 -> @detach(22) [handle=1, closed=true]
[0x7f42b402fdc0]:0 <- @detach(22) [handle=0, closed=true]
[0x7f42b402fdc0]:0 -> @detach(22) [handle=0, closed=true]
[0x7f42b402fdc0]:0 <- @attach(18) [name="auto-2", handle=0, role=false,
snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [durable=0,
expiry-policy=:"session-end", timeout=0, dynamic=false,
outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
:"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
[address="$mqtt.12345.pubrel"], incomplete-unsettled=false,
initial-delivery-count=0]
[0x7f42b402fdc0]:0 <- @detach(22) [handle=0, closed=true]
[0x7f42bc0247c0]:0 <- @close(24) []
[0x7f42bc0247c0]: <- EOS
[0x7f42bc0247c0]:0 -> @close(24) []
[0x7f42bc0247c0]: -> EOS
Thu Dec 1 14:41:52 2016 ROUTER_CORE (info) Link Route Deactivated
'linkRoute/0' on container will-service
Thu Dec 1 14:41:52 2016 ROUTER_CORE (info) Link Route Deactivated
'linkRoute/1' on container will-service
[0x7f42b402fdc0]:0 -> @attach(18) [name="auto-2", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false, outcomes=@PN_SYMBOL[:"amqp:accepted:list",
:"amqp:rejected:list", :"amqp:released:list", :"amqp:modified:list"]],
target=@target(41) [address="$mqtt.12345.pubrel", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x7f42b402fdc0]:0 -> @detach(22) [handle=0, closed=true]
[0x7f42b402fdc0]:0 -> @detach(22) [handle=2, closed=false, error=@error(29)
[condition=:"qd:routed-link-lost", description="Connectivity to the peer
container was lost"]]
[0x7f42b80332a0]:0 -> @detach(22) [handle=2, closed=false, error=@error(29)
[condition=:"qd:routed-link-lost", description="Connectivity to the peer
container was lost"]]
[0x7f42b402fdc0]:0 <- @close(24) []
[0x7f42b402fdc0]: <- EOS
[0x7f42b402fdc0]:0 -> @close(24) []
[0x7f42b402fdc0]: -> EOS
Segmentation fault (core dumped)
{noformat}
this is the backtrace :
{noformat}
#0 0x7f42bc02fc40 in ?? ()
#1 0x7f42d0df1e60 in pn_class_free (clazz=0x7f42bc02fc00,
object=0x7f42bc047260) at /qpid-proton-0.15.0/proton-c/src/object/object.c:117
#2 0x7f42d0df204f in pn_free (object=) at
/qpid-proton-0.15.0/proton-c/src/object/object.c:263
#3 0x7f42d0dfd255 in pn_link_finalize (object=0x7f42bc053160) at
/qpid-proton-0.15.0/proton-c/src/engine/engine.c:1119
#4 0x7f42d0df1e73 in pn_class_free (clazz=0x7f42d1028480 ,
object=0x7f42bc053160) at /qpid-proton-0.15.0/proton-c/src/object/object.c:124
#5 0x7f42d0df204f in pn_free (object=) at
/qpid-proton-0.15.0/proton-c/src/object/object.c:263
#6 0x7f42d0dfc902 in pni_free_children (children=0x7f42bc04dd00,
freed=0x7f42bc04db40) at /qpid-proton-0.15.0/proton-c/src/engine/engine.c:456
#7 0x7f42d0dfd179 in pn_session_finalize (object=0x7f42bc016cd0) at
/qpid-proton-0.15.0/proton-c/src/engine/engine.c:930
#8 0x7f42d0df1e19 in pn_class_decref (clazz=0x7f42d1028500 ,
object=0x7f42bc016cd0) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95
#9 0x7f42d0dfc8d2 in pni_free_children (children=0x7f42b4025700,
freed=0x7f42b4025640) at /qpid-proton-0.15.0/proton-c/src/engine/engine.c:450
#10 0x7f42d0dfd0bb in pn_connection_finalize (object=0x7f42b40430c0) at
/qpid-proton-0.15.0/proton-c/src/engine/engine.c:478
#11 0x7f42d0df1e19 in pn_class_decref (clazz=0x7f42d1028580 ,
object=0x7f42b40430c0) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95
#12 0x7f42d0dffdb0 in pn_event_finalize (event=0x7f42bc054030) at
/qpid-proton-0.15.0/proton-c/src/events/event.c:212
#13 pn_event_finalize_cast (object=0x7f42bc054030) at
/qpid-proton-0.15.0/proton-c/src/events/event.c:257
#14 0x7f42d0df1e19 in pn_class_decref (clazz=0x7f42d1028600 ,
clazz@entry=0x7f42d1027f00 , object=0x7f42bc054030) at
/qpid-proton-0.15.0/proton-c/src/object/object.c:95
#15 0x7f42d0df202f in pn_decref (object=) at
/qpid-proton-0.15.0/proton-c/src/object/object.c:253
#16 0x7f42d0e000a2 in pn_collector_pop
(collector=collector@entry=0x7f42b4026240) at
/qpid-proton-0.15.0/proton-c/src/events/event.c:189
#17 0x7f42d0e000f8 in pn_collector_drain (collector=0x7f42b4026240) at
/qpid-proton-0.15.0/proton-c/src/events/event.c:56
#18 pn_collector_release (collector=0x7f42b4026240) at
/qpid-proton-0.15.0/proton-c/src/events/event.c:118
#19 0x7f42d0e00119 in pn_collector_free (collector=0x7f42b4026240) at
/qpid-proton-
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712081#comment-15712081 ] Paolo Patierno commented on DISPATCH-583: - It seems to be different from mine. I had no AMQP framing error before the crash. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-583: Attachment: qdrouterd.conf > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708895#comment-15708895 ] Paolo Patierno commented on DISPATCH-583: - Attached the router configuration file I'm using. > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-583) Random segmentation fault
Paolo Patierno created DISPATCH-583: --- Summary: Random segmentation fault Key: DISPATCH-583 URL: https://issues.apache.org/jira/browse/DISPATCH-583 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.8.0 Reporter: Paolo Patierno Hello, working with the following project : https://github.com/EnMasseProject/mqtt-frontend using the router, I have random "segmentation fault" errors when the SubscribeTest is executed. It happens running the test 3-4 times ... or 20 times ... totally random. You can reproduce it, cloning the above repo and running : mvn -Dtest=SubscribeTest test I used the route built from the repo source code (about 2 weeks ago) but applying the patch for message annotations on that. I got the backtrace of one of the crash : #0 0x000f00747369 in ?? () #1 0x7f0eceddcf69 in pn_class_equals (clazz=, a=, b=b@entry=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:169 #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, value=value@entry=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/list.c:88 #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, value=value@entry=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/list.c:99 #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at /qpid-proton-0.15.0/proton-c/src/events/event.c:212 #7 pn_event_finalize_cast (object=0x7f0eb802a580) at /qpid-proton-0.15.0/proton-c/src/events/event.c:257 #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 #9 0x7f0eceddd02f in pn_decref (object=) at /qpid-proton-0.15.0/proton-c/src/object/object.c:253 #10 0x7f0ecedeb0a2 in pn_collector_pop (collector=collector@entry=0x7f0eb8036450) at /qpid-proton-0.15.0/proton-c/src/events/event.c:189 #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-572) Adding log info with proton transport id and related remote IP/port
Paolo Patierno created DISPATCH-572: --- Summary: Adding log info with proton transport id and related remote IP/port Key: DISPATCH-572 URL: https://issues.apache.org/jira/browse/DISPATCH-572 Project: Qpid Dispatch Issue Type: Improvement Reporter: Paolo Patierno Hi, enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid Dispatch Router, I need sometimes to know who is the remote peer is exchanging traced messages. For example, considering these few lines of trace (running the Qpid Dispatch Router) : Accepted from 127.0.0.1:48192 Accepted from 127.0.0.1:48190 [0x7fbc44016390]: <- SASL [0x7fbc44016390]: -> SASL [0x7fbc44003b70]: <- SASL [0x7fbc44003b70]: -> SASL [0x7fbc44016390]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] The router accepts two connections from remote clients (we see IP and port) but then every message is related to an "identifier" (I guess it should be the file descriptor related to the used socket). If I need to match these information with Wireshark (where I can see remote port) I don't know if remote clients using remote port 48192 is related to 0x7fbc44016390 or 0x7fbc44003b70. I think it could be a good information to add into the trace at least showing the "identifier" after the accepted message, i.e. : Accepted from 127.0.0.1:48192 [0x7fbc44016390] It's also true, that messages related to something like [0x7fbc44016390] come from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch Router. Thanks, Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1353) Adding message annotations on toString for Message implementation class
Paolo Patierno created PROTON-1353: -- Summary: Adding message annotations on toString for Message implementation class Key: PROTON-1353 URL: https://issues.apache.org/jira/browse/PROTON-1353 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.15.0 Reporter: Paolo Patierno Priority: Minor Adding message annotations on toString for Message implementation class. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1352) Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode
[ https://issues.apache.org/jira/browse/PROTON-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670034#comment-15670034 ] Paolo Patierno commented on PROTON-1352: I opened the following PR for this : > Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode > > > Key: PROTON-1352 > URL: https://issues.apache.org/jira/browse/PROTON-1352 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.15.0 >Reporter: Paolo Patierno >Priority: Minor > > Currently it's not trivial at application level execute casting from > UnsignedByte to SenderSettleMode or ReceiverSettleMode. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (PROTON-1352) Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode
[ https://issues.apache.org/jira/browse/PROTON-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated PROTON-1352: --- Comment: was deleted (was: I opened the following PR for this : ) > Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode > > > Key: PROTON-1352 > URL: https://issues.apache.org/jira/browse/PROTON-1352 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.15.0 >Reporter: Paolo Patierno >Priority: Minor > > Currently it's not trivial at application level execute casting from > UnsignedByte to SenderSettleMode or ReceiverSettleMode. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1352) Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode
Paolo Patierno created PROTON-1352: -- Summary: Trivial casting from UnsignedByte to ReceiverSettleMode and SenderSettleMode Key: PROTON-1352 URL: https://issues.apache.org/jira/browse/PROTON-1352 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.15.0 Reporter: Paolo Patierno Priority: Minor Currently it's not trivial at application level execute casting from UnsignedByte to SenderSettleMode or ReceiverSettleMode. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484156#comment-15484156 ] Paolo Patierno commented on DISPATCH-506: - At router level, with link routing only the connection is opened by the router to the broker/server but the session and related links are opened by the client ... so the session is client specific. > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484089#comment-15484089 ] Paolo Patierno commented on DISPATCH-506: - Saying that the router is the client for the broker/server could be true on using auto-link but it's not completely true for link routing with a virtual connection established between the real client and the broker/server through the router. My perception (but you guys have more experience than me on that) is that customers (in their application) rely much more on the link concept than on connection and session. I saw a lot of applications opening connection/session just because they have to (it's how AMQP works) but then they rely always on "patterns" links related inside that ... of course this consideration (due to my experience) could be totally wrong ;) > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483879#comment-15483879 ] Paolo Patierno edited comment on DISPATCH-506 at 9/12/16 11:43 AM: --- If the router weren't in the middle, the other server would see a dropped TCP connection from the client. In this case the connection level is handled by the router (from it to the server) and the server should have a way to understand that the client dropped the connection in a not clean way. I have to admit that the usage of "closed" flag is not so clear here, but having an "error" with information about a "client TCP connection lost" could be great and clear for the server. You said "there are certainly cases that closing the link if the client dissapears is the wrong thing to do", so you mean that the router should not send the "detach" on behalf of client. What is a case where it could be useful ? was (Author: ppatierno): If the router weren't in the middle, the other server would see a dropped TCP connection from the client. In this case the connection level is handled by the router (from it to the server) and the server should have a way to understand that the client dropped the connection in a not clean way. I have to admit that the usage of "close" flag is not so clear here, but having an "error" with information about a "client TCP connection lost" could be great and clear for the server. You said "there are certainly cases that closing the link if the client dissapears is the wrong thing to do", so you mean that the router should not send the "detach" on behalf of client. What is a case where it could be useful ? > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
[ https://issues.apache.org/jira/browse/DISPATCH-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15483879#comment-15483879 ] Paolo Patierno commented on DISPATCH-506: - If the router weren't in the middle, the other server would see a dropped TCP connection from the client. In this case the connection level is handled by the router (from it to the server) and the server should have a way to understand that the client dropped the connection in a not clean way. I have to admit that the usage of "close" flag is not so clear here, but having an "error" with information about a "client TCP connection lost" could be great and clear for the server. You said "there are certainly cases that closing the link if the client dissapears is the wrong thing to do", so you mean that the router should not send the "detach" on behalf of client. What is a case where it could be useful ? > Detach with no "error" sent by router on client TCP connection dropped > -- > > Key: DISPATCH-506 > URL: https://issues.apache.org/jira/browse/DISPATCH-506 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Paolo Patierno > > Hi, > I got the following scenario. > A router with a link routing configured on address "my_queue". > A broker hosting "my_queue". > A Python receiver connected to that queue through the link routing provided > by the router. > If I kill the receiver, so the TCP connection between client and router is > dropped, the client (of course) doesn't send a detach to the broker for the > link but the router is in charge to do that. > What happens is that this detach message doesn't contain an "error" field in > order to distinguish between a clean detach from the client or a detach sent > by router due to client "brute" disconnection. > Following the trace I have : > [0x16e07f0]: <- EOS > [0x16e07f0]: -> EOS > Closed 127.0.0.1:42308 > Unexpected poll events: 0020 on 127.0.0.1:42308 > [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] > [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] > [0x16cf470]:0 -> @end(23) [] > [0x16cf470]:0 <- @end(23) [] > I think that it could make sense that router sends a detach with "error" when > something like that happens. > The current is a bug or a behavior ? > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-506) Detach with no "error" sent by router on client TCP connection dropped
Paolo Patierno created DISPATCH-506: --- Summary: Detach with no "error" sent by router on client TCP connection dropped Key: DISPATCH-506 URL: https://issues.apache.org/jira/browse/DISPATCH-506 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.1 Reporter: Paolo Patierno Hi, I got the following scenario. A router with a link routing configured on address "my_queue". A broker hosting "my_queue". A Python receiver connected to that queue through the link routing provided by the router. If I kill the receiver, so the TCP connection between client and router is dropped, the client (of course) doesn't send a detach to the broker for the link but the router is in charge to do that. What happens is that this detach message doesn't contain an "error" field in order to distinguish between a clean detach from the client or a detach sent by router due to client "brute" disconnection. Following the trace I have : [0x16e07f0]: <- EOS [0x16e07f0]: -> EOS Closed 127.0.0.1:42308 Unexpected poll events: 0020 on 127.0.0.1:42308 [0x16cf470]:0 -> @detach(22) [handle=0, closed=true] [0x16cf470]:0 <- @detach(22) [handle=0, closed=true] [0x16cf470]:0 -> @end(23) [] [0x16cf470]:0 <- @end(23) [] I think that it could make sense that router sends a detach with "error" when something like that happens. The current is a bug or a behavior ? Thanks, Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-391) Attributes missing for listener and connector and trustedCerts still there
[ https://issues.apache.org/jira/browse/DISPATCH-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15338530#comment-15338530 ] Paolo Patierno commented on DISPATCH-391: - I think that for a reference the alphabetical order could be good but in the official documentation, user task oriented, showing the most used attributes on top could be better. > Attributes missing for listener and connector and trustedCerts still there > -- > > Key: DISPATCH-391 > URL: https://issues.apache.org/jira/browse/DISPATCH-391 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > > Referencing to the qdrouterd.conf reference here : > http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html > Some attributes are missing for listener and connector entities. > listener : > name, host, port, protocolFamily, role, cost > connector: > name, host, port, protocolFamily, role, cost > It seems that all attributes before saslMechanisms are missing. I guess that > this problem could be related to have removed all SSL related attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-397) Error creating a new connector on a router with same name but on another router
[
https://issues.apache.org/jira/browse/DISPATCH-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335945#comment-15335945
]
Paolo Patierno commented on DISPATCH-397:
-
Yes. Absolutely.
> Error creating a new connector on a router with same name but on another
> router
> ---
>
> Key: DISPATCH-397
> URL: https://issues.apache.org/jira/browse/DISPATCH-397
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
> Attachments: Selection_015.png
>
>
> I have a network with three routers A, B and C.
> A is connected to B and a broker with a connector named "BROKER".
> B is connected to C.
> Using the Entities page and selecting router B, I can see the only connector
> from B to C named "INTER_ROUTER.
> If I try to create a new connector for the router B in order to connect it to
> the broker as well using the name "BROKER" for the connector, I receive the
> following error : Duplicate value 'BROKER' for unique attribute 'name'.
> It's true if I create a connector for router A which already has a connector
> with this name, but not true for router B.
> Attached the screenshot of the error.
> At same time the error on the console on the router A is the following :
> Fri Jun 17 09:54:13 2016 AGENT (error) Error dispatching
> Message(address='_topo/0/Router.A/$management', properties={'operation':
> 'CREATE', 'type': 'org.apache.qpid.dispatch.connector', 'name': 'BROKER'},
> body={'role': 'normal', 'type': 'org.apache.qpid.dispatch.connector', 'name':
> 'BROKER', 'port': '5672'},
> reply_to='amqp:/_topo/0/Router.A/temp.3lKIzN7YrrNNvms',
> correlation_id='6363'): org.apache.qpid.dispatch.connector: Duplicate value
> 'BROKER' for unique attribute 'name'
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 813, in handle
> return self.create(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 854, in create
> return (CREATED, self._create(attributes).attributes)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 829, in _create
> self.entities.add_implementation(cimplementation, entity)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 538, in add_implementation
> self._add_implementation(implementation, adapter=adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 535, in _add_implementation
> self.add(adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 524, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities, **kwargs)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 597, in validate_all
> check_singleton=check_singleton)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 574, in validate_entity
> check_singleton=check_singleton)
> File "/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-397) Error creating a new connector on a router with same name but on another router
[
https://issues.apache.org/jira/browse/DISPATCH-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-397:
Attachment: Selection_015.png
> Error creating a new connector on a router with same name but on another
> router
> ---
>
> Key: DISPATCH-397
> URL: https://issues.apache.org/jira/browse/DISPATCH-397
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
> Attachments: Selection_015.png
>
>
> I have a network with three routers A, B and C.
> A is connected to B and a broker with a connector named "BROKER".
> B is connected to C.
> Using the Entities page and selecting router B, I can see the only connector
> from B to C named "INTER_ROUTER.
> If I try to create a new connector for the router B in order to connect it to
> the broker as well using the name "BROKER" for the connector, I receive the
> following error : Duplicate value 'BROKER' for unique attribute 'name'.
> It's true if I create a connector for router A which already has a connector
> with this name, but not true for router B.
> Attached the screenshot of the error.
> At same time the error on the console on the router A is the following :
> Fri Jun 17 09:54:13 2016 AGENT (error) Error dispatching
> Message(address='_topo/0/Router.A/$management', properties={'operation':
> 'CREATE', 'type': 'org.apache.qpid.dispatch.connector', 'name': 'BROKER'},
> body={'role': 'normal', 'type': 'org.apache.qpid.dispatch.connector', 'name':
> 'BROKER', 'port': '5672'},
> reply_to='amqp:/_topo/0/Router.A/temp.3lKIzN7YrrNNvms',
> correlation_id='6363'): org.apache.qpid.dispatch.connector: Duplicate value
> 'BROKER' for unique attribute 'name'
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 813, in handle
> return self.create(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 854, in create
> return (CREATED, self._create(attributes).attributes)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 829, in _create
> self.entities.add_implementation(cimplementation, entity)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 538, in add_implementation
> self._add_implementation(implementation, adapter=adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 535, in _add_implementation
> self.add(adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 524, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities, **kwargs)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 597, in validate_all
> check_singleton=check_singleton)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 574, in validate_entity
> check_singleton=check_singleton)
> File "/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-397) Error creating a new connector on a router with same name but on another router
Paolo Patierno created DISPATCH-397:
---
Summary: Error creating a new connector on a router with same name
but on another router
Key: DISPATCH-397
URL: https://issues.apache.org/jira/browse/DISPATCH-397
Project: Qpid Dispatch
Issue Type: Bug
Components: Console
Affects Versions: 0.6.0
Reporter: Paolo Patierno
I have a network with three routers A, B and C.
A is connected to B and a broker with a connector named "BROKER".
B is connected to C.
Using the Entities page and selecting router B, I can see the only connector
from B to C named "INTER_ROUTER.
If I try to create a new connector for the router B in order to connect it to
the broker as well using the name "BROKER" for the connector, I receive the
following error : Duplicate value 'BROKER' for unique attribute 'name'.
It's true if I create a connector for router A which already has a connector
with this name, but not true for router B.
Attached the screenshot of the error.
At same time the error on the console on the router A is the following :
Fri Jun 17 09:54:13 2016 AGENT (error) Error dispatching
Message(address='_topo/0/Router.A/$management', properties={'operation':
'CREATE', 'type': 'org.apache.qpid.dispatch.connector', 'name': 'BROKER'},
body={'role': 'normal', 'type': 'org.apache.qpid.dispatch.connector', 'name':
'BROKER', 'port': '5672'},
reply_to='amqp:/_topo/0/Router.A/temp.3lKIzN7YrrNNvms', correlation_id='6363'):
org.apache.qpid.dispatch.connector: Duplicate value 'BROKER' for unique
attribute 'name'
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 813, in handle
return self.create(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 854, in create
return (CREATED, self._create(attributes).attributes)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 829, in _create
self.entities.add_implementation(cimplementation, entity)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 538, in add_implementation
self._add_implementation(implementation, adapter=adapter)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 535, in _add_implementation
self.add(adapter)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 524, in add
self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
line 59, in validate_full
super(QdSchema, self).validate_all(entities, **kwargs)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 597, in validate_all
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 574, in validate_entity
check_singleton=check_singleton)
File "/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-391) Attributes missing for listener and connector and trustedCerts still there
[ https://issues.apache.org/jira/browse/DISPATCH-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335583#comment-15335583 ] Paolo Patierno commented on DISPATCH-391: - In my opinion the added attributes should be all displayed before "saslMechanisms" and not at the end of the list. At least name, host, port and role that are the main attributes of these entities. What do you think ? > Attributes missing for listener and connector and trustedCerts still there > -- > > Key: DISPATCH-391 > URL: https://issues.apache.org/jira/browse/DISPATCH-391 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > > Referencing to the qdrouterd.conf reference here : > http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html > Some attributes are missing for listener and connector entities. > listener : > name, host, port, protocolFamily, role, cost > connector: > name, host, port, protocolFamily, role, cost > It seems that all attributes before saslMechanisms are missing. I guess that > this problem could be related to have removed all SSL related attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-396) The "console" entity attributes aren't shown in the qdrouterd.conf
Paolo Patierno created DISPATCH-396: --- Summary: The "console" entity attributes aren't shown in the qdrouterd.conf Key: DISPATCH-396 URL: https://issues.apache.org/jira/browse/DISPATCH-396 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno The "console" entity attributes aren't shown in the qdrouterd.conf. They should be : listener, proxy and args. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-391) Attributes missing for listener and connector and trustedCerts still there
[ https://issues.apache.org/jira/browse/DISPATCH-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-391: Description: Referencing to the qdrouterd.conf reference here : http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html Some attributes are missing for listener and connector entities. listener : host, port, protocolFamily, role, cost connector: name, host, port, protocolFamily, role, cost It seems that all attributes before saslMechanisms are missing. I guess that this problem could be related to have removed all SSL related attributes. Last thing is that trustedCerts is still in the listener and it was not moved to sslProfile. was: Referencing to the qdrouterd.conf reference here : http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html Some attributes are missing for listener and connector entities. listener : host, port, protocolFamily, role, cost connector: name, host, port, protocolFamily, role, cost It seems that all attributes before saslMechanisms are missing. I guess that this problem could be related to have removed all SSL related attributes. Summary: Attributes missing for listener and connector and trustedCerts still there (was: Attributes missing for listener and connector) > Attributes missing for listener and connector and trustedCerts still there > -- > > Key: DISPATCH-391 > URL: https://issues.apache.org/jira/browse/DISPATCH-391 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > > Referencing to the qdrouterd.conf reference here : > http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html > Some attributes are missing for listener and connector entities. > listener : > host, port, protocolFamily, role, cost > connector: > name, host, port, protocolFamily, role, cost > It seems that all attributes before saslMechanisms are missing. I guess that > this problem could be related to have removed all SSL related attributes. > Last thing is that trustedCerts is still in the listener and it was not moved > to sslProfile. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-394) Chart just added isn't shown in the dashboard
Paolo Patierno created DISPATCH-394: --- Summary: Chart just added isn't shown in the dashboard Key: DISPATCH-394 URL: https://issues.apache.org/jira/browse/DISPATCH-394 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.6.0 Reporter: Paolo Patierno If I click on the chart icon for an attribute (i.e. Deliveries to Container for a qdhello entity) and then on add the chart to the dashboard, the chart isn't shown in the dashboard. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-393) Download router configuration doesn't work
Paolo Patierno created DISPATCH-393: --- Summary: Download router configuration doesn't work Key: DISPATCH-393 URL: https://issues.apache.org/jira/browse/DISPATCH-393 Project: Qpid Dispatch Issue Type: Bug Components: Console Reporter: Paolo Patierno Fix For: 0.6.0 It seems that after creating a new router in the topology page, clicking on "Download" ... nothing happens. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-392) "attributeName is undefined error" when showing "address", "linkRoute" and "autoLink"
[
https://issues.apache.org/jira/browse/DISPATCH-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-392:
Description:
I'm using the Ernie Allen docker image in order to run the web console.
https://hub.docker.com/r/ernieallen/dispatch-console/
I have set up my router network and websocket proxy. All works fine but ...
When I open Entities page and click on "address" for example, a pop up shows me
an "attributeName is undefined error" (attached the screenshot) and the AGENT
module on the router shows :
Thu Jun 16 14:00:01 2016 AGENT (error) Error dispatching
Message(address='_topo/0/Router.A/$management', properties={'operation':
'QUERY', 'entityType': 'org.apache.qpid.dispatch.address', 'type':
'org.amqp.management', 'name': 'self'}, body={'attributeNames': []},
reply_to='amqp:/_topo/0/Router.A/temp.Jt5OG0zIxI6o72E', correlation_id='858'):
No such entity type 'org.apache.qpid.dispatch.address'
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 821, in handle
return method(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 611, in query
entity_type = self.requested_type(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 606, in requested_type
if type: return self._schema.entity_type(type)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 551, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 547, in _lookup
raise ValidationError(message % name)
ValidationError: No such entity type 'org.apache.qpid.dispatch.address'
It should be something in the query, because if I executes :
qdmanage -b localhost:6000 query --type address
I receive a good result :
[
{
"egressPhase": 0,
"ingressPhase": 0,
"prefix": "my_address",
"waypoint": false,
"distribution": "closest",
"type": "org.apache.qpid.dispatch.router.config.address",
"identity": "1"
},
{
"egressPhase": 1,
"ingressPhase": 0,
"prefix": "my_queue_wp",
"waypoint": true,
"distribution": "balanced",
"type": "org.apache.qpid.dispatch.router.config.address",
"identity": "2"
}
]
I can see the same problem with "linkRoute" and "autoLink".
was:
I'm using the Ernie Allen docker image in order to run the web console.
https://hub.docker.com/r/ernieallen/dispatch-console/
I have set up my router network and websocket proxy. All works fine but ...
When I open Entities page and click on "address" for example, a pop up shows me
an "attributeName is undefined error" and the AGENT module on the router shows :
Thu Jun 16 14:00:01 2016 AGENT (error) Error dispatching
Message(address='_topo/0/Router.A/$management', properties={'operation':
'QUERY', 'entityType': 'org.apache.qpid.dispatch.address', 'type':
'org.amqp.management', 'name': 'self'}, body={'attributeNames': []},
reply_to='amqp:/_topo/0/Router.A/temp.Jt5OG0zIxI6o72E', correlation_id='858'):
No such entity type 'org.apache.qpid.dispatch.address'
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 821, in handle
return method(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 611, in query
entity_type = self.requested_type(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 606, in requested_type
if type: return self._schema.entity_type(type)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 551, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 547, in _lookup
raise ValidationError(message % name)
ValidationError: No such entity type 'org.apache.qpid.dispatch.address'
It should be something in the query, because if I executes :
qdmanage -b localhost:6000 query --type address
I receive a good result :
[
{
"egressPhase": 0,
"ingressPhase": 0,
"prefix": "my_address",
"waypoint": false,
"distribution": "closest",
"type": "org.apache.qpid.dispatch.router.config.address",
"identity": "1"
},
{
"egressPhase": 1,
"ingressPhase": 0,
"prefix": "my_queue_wp",
[jira] [Updated] (DISPATCH-392) "attributeName is undefined error" when showing "address", "linkRoute" and "autoLink"
[
https://issues.apache.org/jira/browse/DISPATCH-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-392:
Attachment: Selection_015.png
> "attributeName is undefined error" when showing "address", "linkRoute" and
> "autoLink"
> -
>
> Key: DISPATCH-392
> URL: https://issues.apache.org/jira/browse/DISPATCH-392
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
> Attachments: Selection_015.png
>
>
> I'm using the Ernie Allen docker image in order to run the web console.
> https://hub.docker.com/r/ernieallen/dispatch-console/
> I have set up my router network and websocket proxy. All works fine but ...
> When I open Entities page and click on "address" for example, a pop up shows
> me an "attributeName is undefined error" and the AGENT module on the router
> shows :
> Thu Jun 16 14:00:01 2016 AGENT (error) Error dispatching
> Message(address='_topo/0/Router.A/$management', properties={'operation':
> 'QUERY', 'entityType': 'org.apache.qpid.dispatch.address', 'type':
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []},
> reply_to='amqp:/_topo/0/Router.A/temp.Jt5OG0zIxI6o72E',
> correlation_id='858'): No such entity type 'org.apache.qpid.dispatch.address'
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 821, in handle
> return method(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 611, in query
> entity_type = self.requested_type(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 606, in requested_type
> if type: return self._schema.entity_type(type)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 551, in entity_type
> return self._lookup(self.entity_types, name, "No such entity type '%s'",
> error)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 547, in _lookup
> raise ValidationError(message % name)
> ValidationError: No such entity type 'org.apache.qpid.dispatch.address'
> It should be something in the query, because if I executes :
> qdmanage -b localhost:6000 query --type address
> I receive a good result :
> [
> {
> "egressPhase": 0,
> "ingressPhase": 0,
> "prefix": "my_address",
> "waypoint": false,
> "distribution": "closest",
> "type": "org.apache.qpid.dispatch.router.config.address",
> "identity": "1"
> },
> {
> "egressPhase": 1,
> "ingressPhase": 0,
> "prefix": "my_queue_wp",
> "waypoint": true,
> "distribution": "balanced",
> "type": "org.apache.qpid.dispatch.router.config.address",
> "identity": "2"
> }
> ]
> I can see the same problem with "linkRoute" and "autoLink".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-392) "attributeName is undefined error" when showing "address", "linkRoute" and "autoLink"
Paolo Patierno created DISPATCH-392:
---
Summary: "attributeName is undefined error" when showing
"address", "linkRoute" and "autoLink"
Key: DISPATCH-392
URL: https://issues.apache.org/jira/browse/DISPATCH-392
Project: Qpid Dispatch
Issue Type: Bug
Components: Console
Affects Versions: 0.6.0
Reporter: Paolo Patierno
Attachments: Selection_015.png
I'm using the Ernie Allen docker image in order to run the web console.
https://hub.docker.com/r/ernieallen/dispatch-console/
I have set up my router network and websocket proxy. All works fine but ...
When I open Entities page and click on "address" for example, a pop up shows me
an "attributeName is undefined error" and the AGENT module on the router shows :
Thu Jun 16 14:00:01 2016 AGENT (error) Error dispatching
Message(address='_topo/0/Router.A/$management', properties={'operation':
'QUERY', 'entityType': 'org.apache.qpid.dispatch.address', 'type':
'org.amqp.management', 'name': 'self'}, body={'attributeNames': []},
reply_to='amqp:/_topo/0/Router.A/temp.Jt5OG0zIxI6o72E', correlation_id='858'):
No such entity type 'org.apache.qpid.dispatch.address'
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 821, in handle
return method(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 611, in query
entity_type = self.requested_type(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 606, in requested_type
if type: return self._schema.entity_type(type)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 551, in entity_type
return self._lookup(self.entity_types, name, "No such entity type '%s'",
error)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 547, in _lookup
raise ValidationError(message % name)
ValidationError: No such entity type 'org.apache.qpid.dispatch.address'
It should be something in the query, because if I executes :
qdmanage -b localhost:6000 query --type address
I receive a good result :
[
{
"egressPhase": 0,
"ingressPhase": 0,
"prefix": "my_address",
"waypoint": false,
"distribution": "closest",
"type": "org.apache.qpid.dispatch.router.config.address",
"identity": "1"
},
{
"egressPhase": 1,
"ingressPhase": 0,
"prefix": "my_queue_wp",
"waypoint": true,
"distribution": "balanced",
"type": "org.apache.qpid.dispatch.router.config.address",
"identity": "2"
}
]
I can see the same problem with "linkRoute" and "autoLink".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-391) Attributes missing for listener and connector
Paolo Patierno created DISPATCH-391: --- Summary: Attributes missing for listener and connector Key: DISPATCH-391 URL: https://issues.apache.org/jira/browse/DISPATCH-391 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno Referencing to the qdrouterd.conf reference here : http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html Some attributes are missing for listener and connector entities. listener : host, port, protocolFamily, role, cost connector: name, host, port, protocolFamily, role, cost It seems that all attributes before saslMechanisms are missing. I guess that this problem could be related to have removed all SSL related attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-389) Removing CONFIG and DISPATCH as modules for logging
Paolo Patierno created DISPATCH-389: --- Summary: Removing CONFIG and DISPATCH as modules for logging Key: DISPATCH-389 URL: https://issues.apache.org/jira/browse/DISPATCH-389 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno Priority: Minor The CONFIG and DISPATCH modules seem to be not used for logging so they should be removed from schema and documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-384) qdrouter.conf manual : saslMechanisms as "Space separated list ..."
Paolo Patierno created DISPATCH-384: --- Summary: qdrouter.conf manual : saslMechanisms as "Space separated list ..." Key: DISPATCH-384 URL: https://issues.apache.org/jira/browse/DISPATCH-384 Project: Qpid Dispatch Issue Type: Bug Reporter: Paolo Patierno Priority: Minor Fix For: 0.6.0 The qdrouterd.conf manual says that "saslMechanisms" attribute is a "Comma separated list ". Instead it should be a "Space separated list ..." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-376) The same linkRoute (in both directions) is configurable twice
Paolo Patierno created DISPATCH-376:
---
Summary: The same linkRoute (in both directions) is configurable
twice
Key: DISPATCH-376
URL: https://issues.apache.org/jira/browse/DISPATCH-376
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Paolo Patierno
Considering following configuration :
linkRoute {
prefix: myqueue
connection: BROKER
dir: in
}
linkRoute {
prefix: myqueue
connection: BROKER
dir: out
}
linkRoute {
prefix: myqueue
connection: BROKER
dir: in
}
linkRoute {
prefix: myqueue
connection: BROKER
dir: out
}
It's a linkRoute (in both directions) defined twice.
It should be a misconfiguration we should probably not permit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-374) qdmanage: using --type option with --name (or --identity) option causes a "Not found"
[
https://issues.apache.org/jira/browse/DISPATCH-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15322151#comment-15322151
]
Paolo Patierno commented on DISPATCH-374:
-
I have just checked that the same is valid for "delete" operation.
[root@localhost /]# qdmanage -b localhost:5673 delete --type address --name
my_address_name
NotFoundStatus: Not Found
[root@localhost /]# qdmanage -b localhost:5673 delete --type address --name
my_queue_in
NotFoundStatus: Not Found
no AGENT error on the router side.
Without --type option it works.
[root@localhost /]# qdmanage -b localhost:5673 delete --name my_address_name
(with no output on the console)
at same time if I tried it with a wrong "connector" name for example.
[root@localhost /]# qdmanage -b localhost:5673 delete --type connector --name
BROKER1
NotFoundStatus: No entity with name='BROKER1'
it shows a more complete NotFoundStatus and the router shows an AGENT error.
Thu Jun 9 08:31:14 2016 AGENT (error) Error dispatching Message(address=None,
properties={'operation': 'DELETE', 'type':
'org.apache.qpid.dispatch.connector', 'name': 'BROKER1'}, body={},
reply_to='amqp:/_topo/0/Router.A/temp.tfhMrWEbkVGQ+54', correlation_id=1L): No
entity with name='BROKER1'
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 815, in handle
target = self.find_entity(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 906, in find_entity
raise NotFoundStatus("No entity with %s" % attrvals())
NotFoundStatus: No entity with name='BROKER1'
> qdmanage: using --type option with --name (or --identity) option causes a
> "Not found"
> -
>
> Key: DISPATCH-374
> URL: https://issues.apache.org/jira/browse/DISPATCH-374
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>
> Using the read operation with both --type and --name (or --identity) option
> works fine for something like a "connector" for example.
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
> BROKER
> {
> "verifyHostName": true,
> "stripAnnotations": "both",
> "name": "BROKER",
> "allowRedirect": true,
> "idleTimeoutSeconds": 16,
> "maxFrameSize": 65536,
> "host": "127.0.0.1",
> "cost": 1,
> "role": "route-container",
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5672",
> "identity": "connector/127.0.0.1:5672:BROKER",
> "addr": "127.0.0.1"
> }
> Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
> error :
> [root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
> my_queue_out
> NotFoundStatus: Not Found
> but executing same command without --type specified, it works well.
> [root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
> {
> "name": "my_queue_out",
> "prefix": "my_queue",
> "connection": "BROKER",
> "identity": "linkRoute/1",
> "distribution": "linkBalanced",
> "type": "org.apache.qpid.dispatch.router.config.linkRoute",
> "dir": "out"
> }
> I'd like to add that trying with a non exsisting name for a connector (for
> example), the error is the following :
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
> BROKER1
> NotFoundStatus: No entity with name='BROKER1'
> at same time router produce an AGENT error on the console.
> It seems that the NotFoundStatus message is different for linkRoute, address
> (and I guess autoLink).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-374) qdmanage: using --type option with --name (or --identity) option causes a "Not found"
[
https://issues.apache.org/jira/browse/DISPATCH-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-374:
Description:
Using the read operation with both --type and --name (or --identity) option
works fine for something like a "connector" for example.
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER
{
"verifyHostName": true,
"stripAnnotations": "both",
"name": "BROKER",
"allowRedirect": true,
"idleTimeoutSeconds": 16,
"maxFrameSize": 65536,
"host": "127.0.0.1",
"cost": 1,
"role": "route-container",
"type": "org.apache.qpid.dispatch.connector",
"port": "5672",
"identity": "connector/127.0.0.1:5672:BROKER",
"addr": "127.0.0.1"
}
Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
error :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
my_queue_out
NotFoundStatus: Not Found
but executing same command without --type specified, it works well.
[root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
{
"name": "my_queue_out",
"prefix": "my_queue",
"connection": "BROKER",
"identity": "linkRoute/1",
"distribution": "linkBalanced",
"type": "org.apache.qpid.dispatch.router.config.linkRoute",
"dir": "out"
}
I'd like to add that trying with a non exsisting name for a connector (for
example), the error is the following :
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER1
NotFoundStatus: No entity with name='BROKER1'
at same time router produce an AGENT error on the console.
It seems that the NotFoundStatus message is different for linkRoute, address
(and I guess autoLink).
was:
Using the read operation with both --type and --name (or --identity) option
works fine for something like a "connecto" for example.
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER
{
"verifyHostName": true,
"stripAnnotations": "both",
"name": "BROKER",
"allowRedirect": true,
"idleTimeoutSeconds": 16,
"maxFrameSize": 65536,
"host": "127.0.0.1",
"cost": 1,
"role": "route-container",
"type": "org.apache.qpid.dispatch.connector",
"port": "5672",
"identity": "connector/127.0.0.1:5672:BROKER",
"addr": "127.0.0.1"
}
Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
error :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
my_queue_out
NotFoundStatus: Not Found
but executing same command without --type specified, it works well.
[root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
{
"name": "my_queue_out",
"prefix": "my_queue",
"connection": "BROKER",
"identity": "linkRoute/1",
"distribution": "linkBalanced",
"type": "org.apache.qpid.dispatch.router.config.linkRoute",
"dir": "out"
}
I'd like to add that trying with a non exsisting name for a connector (for
example), the error is the following :
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER1
NotFoundStatus: No entity with name='BROKER1'
at same time router produce an AGENT error on the console.
It seems that the NotFoundStatus message is different for linkRoute, address
(and I guess autoLink).
> qdmanage: using --type option with --name (or --identity) option causes a
> "Not found"
> -
>
> Key: DISPATCH-374
> URL: https://issues.apache.org/jira/browse/DISPATCH-374
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>
> Using the read operation with both --type and --name (or --identity) option
> works fine for something like a "connector" for example.
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
> BROKER
> {
> "verifyHostName": true,
> "stripAnnotations": "both",
> "name": "BROKER",
> "allowRedirect": true,
> "idleTimeoutSeconds": 16,
> "maxFrameSize": 65536,
> "host": "127.0.0.1",
> "cost": 1,
> "role": "route-container",
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5672",
> "identity": "connector/127.0.0.1:5672:BROKER",
> "addr": "127.0.0.1"
> }
> Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
> error :
> [root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
> my_queue_out
> NotFoundStatus: Not Found
> but executing same command without --type specified, it works well.
> [root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
> {
> "name": "my_queue_out",
> "prefix": "my_queue",
> "connection": "BROKER",
> "identity": "linkRoute/1",
> "distribution": "linkBalanced",
> "type": "org.apache.qpid.dispatch.router.config.li
[jira] [Commented] (DISPATCH-373) qdmanage : no clear error message when "read" type linkRoute, address and autoLink
[
https://issues.apache.org/jira/browse/DISPATCH-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15322145#comment-15322145
]
Paolo Patierno commented on DISPATCH-373:
-
I have just checked that it's the same with "delete" operation ...
[root@localhost /]# qdmanage -b localhost:5673 delete --type linkRoute
BadRequestStatus: Bad Request
[root@localhost /]# qdmanage -b localhost:5673 delete --type address
BadRequestStatus: Bad Request
[root@localhost /]# qdmanage -b localhost:5673 delete --type autoLink
BadRequestStatus: Bad Request
with no AGENT error on the router.
It works fine with another entity (i.e. connector).
[root@localhost /]# qdmanage -b localhost:5673 delete --type connector
BadRequestStatus: No name or identity provided
with AGENT error on the router.
Thu Jun 9 08:23:37 2016 AGENT (error) Error dispatching Message(address=None,
properties={'operation': 'DELETE', 'type':
'org.apache.qpid.dispatch.connector'}, body={},
reply_to='amqp:/_topo/0/Router.A/temp.72AghI2_aUKEPEe', correlation_id=1L): No
name or identity provided
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 815, in handle
target = self.find_entity(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 892, in find_entity
raise BadRequestStatus("No name or identity provided")
BadRequestStatus: No name or identity provided
> qdmanage : no clear error message when "read" type linkRoute, address and
> autoLink
> --
>
> Key: DISPATCH-373
> URL: https://issues.apache.org/jira/browse/DISPATCH-373
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>
> Executing a bad request with "read" operation (only ---type option) produces
> following results for linkRoute, address and autoLink :
> [root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute
> BadRequestStatus: Bad Request
> [root@localhost /]# qdmanage -b localhost:5673 read --type address
> BadRequestStatus: Bad Request
> [root@localhost /]# qdmanage -b localhost:5673 read --type autoLink
> BadRequestStatus: Bad Request
> and the router doesn't produce any error or output on the console.
> Instead, using another type, for example connector produces following result :
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector
> BadRequestStatus: No name or identity provided
> with a clearer error on what user misses on the command line.
> At same time the router output shows following error to the console :
> Thu Jun 9 07:26:13 2016 AGENT (error) Error dispatching
> Message(address=None, properties={'operation': 'READ', 'type':
> 'org.apache.qpid.dispatch.connector'}, body={},
> reply_to='amqp:/_topo/0/Router.A/temp.JJRdbcd9RbPxemN', correlation_id=1L):
> No name or identity provided
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 815, in handle
> target = self.find_entity(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 892, in find_entity
> raise BadRequestStatus("No name or identity provided")
> BadRequestStatus: No name or identity provided
> I guess that for all types provided, missing name or identity, the behavior
> should be the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-374) qdmanage: using --type option with --name (or --identity) option causes a "Not found"
[
https://issues.apache.org/jira/browse/DISPATCH-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno updated DISPATCH-374:
Description:
Using the read operation with both --type and --name (or --identity) option
works fine for something like a "connecto" for example.
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER
{
"verifyHostName": true,
"stripAnnotations": "both",
"name": "BROKER",
"allowRedirect": true,
"idleTimeoutSeconds": 16,
"maxFrameSize": 65536,
"host": "127.0.0.1",
"cost": 1,
"role": "route-container",
"type": "org.apache.qpid.dispatch.connector",
"port": "5672",
"identity": "connector/127.0.0.1:5672:BROKER",
"addr": "127.0.0.1"
}
Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
error :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
my_queue_out
NotFoundStatus: Not Found
but executing same command without --type specified, it works well.
[root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
{
"name": "my_queue_out",
"prefix": "my_queue",
"connection": "BROKER",
"identity": "linkRoute/1",
"distribution": "linkBalanced",
"type": "org.apache.qpid.dispatch.router.config.linkRoute",
"dir": "out"
}
I'd like to add that trying with a non exsisting name for a connector (for
example), the error is the following :
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER1
NotFoundStatus: No entity with name='BROKER1'
at same time router produce an AGENT error on the console.
It seems that the NotFoundStatus message is different for linkRoute, address
(and I guess autoLink).
was:
Using the read operation with both --type and --name (or --identity) option
works fine for something like a "connecto" for example.
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER
{
"verifyHostName": true,
"stripAnnotations": "both",
"name": "BROKER",
"allowRedirect": true,
"idleTimeoutSeconds": 16,
"maxFrameSize": 65536,
"host": "127.0.0.1",
"cost": 1,
"role": "route-container",
"type": "org.apache.qpid.dispatch.connector",
"port": "5672",
"identity": "connector/127.0.0.1:5672:BROKER",
"addr": "127.0.0.1"
}
Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
error :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
my_queue_out
NotFoundStatus: Not Found
but executing same command without --type specified, it works well.
[root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
{
"name": "my_queue_out",
"prefix": "my_queue",
"connection": "BROKER",
"identity": "linkRoute/1",
"distribution": "linkBalanced",
"type": "org.apache.qpid.dispatch.router.config.linkRoute",
"dir": "out"
}
> qdmanage: using --type option with --name (or --identity) option causes a
> "Not found"
> -
>
> Key: DISPATCH-374
> URL: https://issues.apache.org/jira/browse/DISPATCH-374
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>
> Using the read operation with both --type and --name (or --identity) option
> works fine for something like a "connecto" for example.
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
> BROKER
> {
> "verifyHostName": true,
> "stripAnnotations": "both",
> "name": "BROKER",
> "allowRedirect": true,
> "idleTimeoutSeconds": 16,
> "maxFrameSize": 65536,
> "host": "127.0.0.1",
> "cost": 1,
> "role": "route-container",
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5672",
> "identity": "connector/127.0.0.1:5672:BROKER",
> "addr": "127.0.0.1"
> }
> Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
> error :
> [root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
> my_queue_out
> NotFoundStatus: Not Found
> but executing same command without --type specified, it works well.
> [root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
> {
> "name": "my_queue_out",
> "prefix": "my_queue",
> "connection": "BROKER",
> "identity": "linkRoute/1",
> "distribution": "linkBalanced",
> "type": "org.apache.qpid.dispatch.router.config.linkRoute",
> "dir": "out"
> }
> I'd like to add that trying with a non exsisting name for a connector (for
> example), the error is the following :
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
> BROKER1
> NotFoundStatus: No entity with name='BROKER1'
> at same time router produce an AGENT error on the console.
> It seems that the NotFoundStatus message is different for link
[jira] [Created] (DISPATCH-374) qdmanage: using --type option with --name (or --identity) option causes a "Not found"
Paolo Patierno created DISPATCH-374:
---
Summary: qdmanage: using --type option with --name (or --identity)
option causes a "Not found"
Key: DISPATCH-374
URL: https://issues.apache.org/jira/browse/DISPATCH-374
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Paolo Patierno
Using the read operation with both --type and --name (or --identity) option
works fine for something like a "connecto" for example.
[root@localhost /]# qdmanage -b localhost:5673 read --type connector --name
BROKER
{
"verifyHostName": true,
"stripAnnotations": "both",
"name": "BROKER",
"allowRedirect": true,
"idleTimeoutSeconds": 16,
"maxFrameSize": 65536,
"host": "127.0.0.1",
"cost": 1,
"role": "route-container",
"type": "org.apache.qpid.dispatch.connector",
"port": "5672",
"identity": "connector/127.0.0.1:5672:BROKER",
"addr": "127.0.0.1"
}
Using it for a linkRoute, address (and I guess autoLink) produces a NotFound
error :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute --name
my_queue_out
NotFoundStatus: Not Found
but executing same command without --type specified, it works well.
[root@localhost /]# qdmanage -b localhost:5673 read --name my_queue_out
{
"name": "my_queue_out",
"prefix": "my_queue",
"connection": "BROKER",
"identity": "linkRoute/1",
"distribution": "linkBalanced",
"type": "org.apache.qpid.dispatch.router.config.linkRoute",
"dir": "out"
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-373) qdmanage : no clear error message when "read" type linkRoute, address and autoLink
Paolo Patierno created DISPATCH-373:
---
Summary: qdmanage : no clear error message when "read" type
linkRoute, address and autoLink
Key: DISPATCH-373
URL: https://issues.apache.org/jira/browse/DISPATCH-373
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Paolo Patierno
Executing a bad request with "read" operation (only ---type option) produces
following results for linkRoute, address and autoLink :
[root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute
BadRequestStatus: Bad Request
[root@localhost /]# qdmanage -b localhost:5673 read --type address
BadRequestStatus: Bad Request
[root@localhost /]# qdmanage -b localhost:5673 read --type autoLink
BadRequestStatus: Bad Request
and the router doesn't produce any error or output on the console.
Instead, using another type, for example connector produces following result :
[root@localhost /]# qdmanage -b localhost:5673 read --type connector
BadRequestStatus: No name or identity provided
with a clearer error on what user misses on the command line.
At same time the router output shows following error to the console :
Thu Jun 9 07:26:13 2016 AGENT (error) Error dispatching Message(address=None,
properties={'operation': 'READ', 'type': 'org.apache.qpid.dispatch.connector'},
body={}, reply_to='amqp:/_topo/0/Router.A/temp.JJRdbcd9RbPxemN',
correlation_id=1L): No name or identity provided
Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 790, in receive
status, body = self.handle(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 815, in handle
target = self.find_entity(request)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
line 892, in find_entity
raise BadRequestStatus("No name or identity provided")
BadRequestStatus: No name or identity provided
I guess that for all types provided, missing name or identity, the behavior
should be the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute"
Paolo Patierno created DISPATCH-370: --- Summary: qdmanage tool hangs if --type option is "linkRoute" Key: DISPATCH-370 URL: https://issues.apache.org/jira/browse/DISPATCH-370 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno Using qdmanage tool in the following way : qdmanage read --type linkRoute it doesn't reply with : BadRequestStatus: No name or identity provided but hangs and then exit for timeout : Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for response -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute" or "address"
[ https://issues.apache.org/jira/browse/DISPATCH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-370: Description: Using qdmanage tool in the following way : qdmanage read --type linkRoute it doesn't reply with : BadRequestStatus: No name or identity provided but hangs and then exit for timeout : Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for response The same happens using "address" as type. was: Using qdmanage tool in the following way : qdmanage read --type linkRoute it doesn't reply with : BadRequestStatus: No name or identity provided but hangs and then exit for timeout : Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for response Summary: qdmanage tool hangs if --type option is "linkRoute" or "address" (was: qdmanage tool hangs if --type option is "linkRoute") > qdmanage tool hangs if --type option is "linkRoute" or "address" > > > Key: DISPATCH-370 > URL: https://issues.apache.org/jira/browse/DISPATCH-370 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno > > Using qdmanage tool in the following way : > qdmanage read --type linkRoute > it doesn't reply with : > BadRequestStatus: No name or identity provided > but hangs and then exit for timeout : > Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for > response > The same happens using "address" as type. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output
[ https://issues.apache.org/jira/browse/DISPATCH-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-357: Description: I have a router with a link routed link for address "my_queue" configured (in both directions in and out). Executing "qdstat -l", it doesn't show me the address name; the "addr" field is empty. Attached you can find the file with output. was: I have a router with a link routed link for address "my_queue" configured (in both directions in and out). Executing "qdstat -l", it doesn't show me the address name; the "addr" field is empty. Router Links typedir conn id id peer class addr phs cap undel unsettled deliveries adminoper = router-control in 27 250 0 0 2876enabled up router-control out 28 local qdhello 250 0 0 2716enabled up inter-routerin 29 250 0 0 1 enabled up inter-routerout 210 250 0 0 1 enabled up endpointin 111mobile my_queue_wp 1 250 0 0 3 enabled up endpointout 112mobile my_queue_wp 0 250 0 0 3 enabled up endpointout 415mobile my_address0 250 0 0 0 enabled up endpointout 618 19 250 0 0 1 enabled up endpointin 119 18 0 0 0 1 enabled up endpointout 19 40mobile my_queue_wp 1 250 0 0 1 enabled up endpointin 24 48mobile $management 0 250 0 0 1 enabled up endpointout 24 49local temp.mx5HxzUe2Eddw_s 250 0 0 0 enabled up > Address field is empty for link routed links in the qdstat "links" output > - > > Key: DISPATCH-357 > URL: https://issues.apache.org/jira/browse/DISPATCH-357 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno > Attachments: qdstat_links.txt > > > I have a router with a link routed link for address "my_queue" configured (in > both directions in and out). > Executing "qdstat -l", it doesn't show me the address name; the "addr" field > is empty. > Attached you can find the file with output. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output
[ https://issues.apache.org/jira/browse/DISPATCH-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-357: Attachment: qdstat_links.txt > Address field is empty for link routed links in the qdstat "links" output > - > > Key: DISPATCH-357 > URL: https://issues.apache.org/jira/browse/DISPATCH-357 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno > Attachments: qdstat_links.txt > > > I have a router with a link routed link for address "my_queue" configured (in > both directions in and out). > Executing "qdstat -l", it doesn't show me the address name; the "addr" field > is empty. > Router Links > typedir conn id id peer class addr phs > cap undel unsettled deliveries adminoper > > = > router-control in 27 > 250 0 0 2876enabled up > router-control out 28 local qdhello > 250 0 0 2716enabled up > inter-routerin 29 > 250 0 0 1 enabled up > inter-routerout 210 > 250 0 0 1 enabled up > endpointin 111mobile my_queue_wp 1 > 250 0 0 3 enabled up > endpointout 112mobile my_queue_wp 0 > 250 0 0 3 enabled up > endpointout 415mobile my_address0 > 250 0 0 0 enabled up > endpointout 618 19 > 250 0 0 1 enabled up > endpointin 119 18 > 00 0 1 enabled up > endpointout 19 40mobile my_queue_wp 1 > 250 0 0 1 enabled up > endpointin 24 48mobile $management 0 > 250 0 0 1 enabled up > endpointout 24 49local temp.mx5HxzUe2Eddw_s > 250 0 0 0 enabled up -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output
Paolo Patierno created DISPATCH-357: --- Summary: Address field is empty for link routed links in the qdstat "links" output Key: DISPATCH-357 URL: https://issues.apache.org/jira/browse/DISPATCH-357 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno Attachments: qdstat_links.txt I have a router with a link routed link for address "my_queue" configured (in both directions in and out). Executing "qdstat -l", it doesn't show me the address name; the "addr" field is empty. Router Links typedir conn id id peer class addr phs cap undel unsettled deliveries adminoper = router-control in 27 250 0 0 2876enabled up router-control out 28 local qdhello 250 0 0 2716enabled up inter-routerin 29 250 0 0 1 enabled up inter-routerout 210 250 0 0 1 enabled up endpointin 111mobile my_queue_wp 1 250 0 0 3 enabled up endpointout 112mobile my_queue_wp 0 250 0 0 3 enabled up endpointout 415mobile my_address0 250 0 0 0 enabled up endpointout 618 19 250 0 0 1 enabled up endpointin 119 18 0 0 0 1 enabled up endpointout 19 40mobile my_queue_wp 1 250 0 0 1 enabled up endpointin 24 48mobile $management 0 250 0 0 1 enabled up endpointout 24 49local temp.mx5HxzUe2Eddw_s 250 0 0 0 enabled up -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-354) qdstat general statistics broken
Paolo Patierno created DISPATCH-354: --- Summary: qdstat general statistics broken Key: DISPATCH-354 URL: https://issues.apache.org/jira/browse/DISPATCH-354 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6.0 Reporter: Paolo Patierno I have a router with default configuration and two receivers attached for a simple "my_address" address. I can see the address using qdstat -a and the links using qdstat -l but the qdstat -g option reports always Address Count 0 and Link Count 0. Even, when I have two routers connected the qdstat -g option shows Link Count 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-347) Negative SASL outome when "requireEncryption" isn't satisfied
Paolo Patierno created DISPATCH-347: --- Summary: Negative SASL outome when "requireEncryption" isn't satisfied Key: DISPATCH-347 URL: https://issues.apache.org/jira/browse/DISPATCH-347 Project: Qpid Dispatch Issue Type: Wish Affects Versions: 0.6.0 Reporter: Paolo Patierno Priority: Minor If we configure the router with requireEncryption set to true but the client connect using a SASL mechanism which doesn't support encryption (i.e. ANONYMOUS, PLAIN, ...) the SASL exchange goes well with a successful outcome but the router close the TCP connection brutally after that. The client doesn't have any reason why it happens. The SASL RFC (https://tools.ietf.org/html/rfc4422) in the "Authentication Outcome" says that "The outcome is not successful if ..." ... "the negotiated security layer (or lack thereof) is not suitable ...". I think that above scenario is a "lack" of requested security so the SASL outcome to the client shouldn't be positive but negative. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-295) Router aborted on assertion failed after socker closing by client
[ https://issues.apache.org/jira/browse/DISPATCH-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257950#comment-15257950 ] Paolo Patierno commented on DISPATCH-295: - I'm on the last bits on GitHub cloned and compiled this morning. Paolo. > Router aborted on assertion failed after socker closing by client > - > > Key: DISPATCH-295 > URL: https://issues.apache.org/jira/browse/DISPATCH-295 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Paolo Patierno > Attachments: qdrouterd_abort.pcap, qdrouterd_abort.txt > > > I'm just trying to send the CBS token to Azure (for now I have no reply and > I'll investigate in the next days) with a simple Java application through the > qpid dispatch router. > Attached you can find the wireshark pcap file (filter on tcp.port == 5672) > and a text file with qdrouterd trace. > After sending the CBS token (with no reply from Azure), there are a couple of > empty frames as heartbeat and then I "stop" the Java application from the IDE > (Eclipse). > At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but > the router crashes with following error on a failed assert : > qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion > `result == 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-295) Router aborted on assertion failed after socker closing by client
[ https://issues.apache.org/jira/browse/DISPATCH-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-295: Attachment: qdrouterd_abort.pcap > Router aborted on assertion failed after socker closing by client > - > > Key: DISPATCH-295 > URL: https://issues.apache.org/jira/browse/DISPATCH-295 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Paolo Patierno > Attachments: qdrouterd_abort.pcap, qdrouterd_abort.txt > > > I'm just trying to send the CBS token to Azure (for now I have no reply and > I'll investigate in the next days) with a simple Java application through the > qpid dispatch router. > Attached you can find the wireshark pcap file (filter on tcp.port == 5672) > and a text file with qdrouterd trace. > After sending the CBS token (with no reply from Azure), there are a couple of > empty frames as heartbeat and then I "stop" the Java application from the IDE > (Eclipse). > At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but > the router crashes (?) with following error on a failed assert : > qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion > `result == 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-295) Router aborted on assertion failed after socker closing by client
[ https://issues.apache.org/jira/browse/DISPATCH-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-295: Description: I'm just trying to send the CBS token to Azure (for now I have no reply and I'll investigate in the next days) with a simple Java application through the qpid dispatch router. Attached you can find the wireshark pcap file (filter on tcp.port == 5672) and a text file with qdrouterd trace. After sending the CBS token (with no reply from Azure), there are a couple of empty frames as heartbeat and then I "stop" the Java application from the IDE (Eclipse). At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but the router crashes with following error on a failed assert : qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted (core dumped) was: I'm just trying to send the CBS token to Azure (for now I have no reply and I'll investigate in the next days) with a simple Java application through the qpid dispatch router. Attached you can find the wireshark pcap file (filter on tcp.port == 5672) and a text file with qdrouterd trace. After sending the CBS token (with no reply from Azure), there are a couple of empty frames as heartbeat and then I "stop" the Java application from the IDE (Eclipse). At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but the router crashes (?) with following error on a failed assert : qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted (core dumped) > Router aborted on assertion failed after socker closing by client > - > > Key: DISPATCH-295 > URL: https://issues.apache.org/jira/browse/DISPATCH-295 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Paolo Patierno > Attachments: qdrouterd_abort.pcap, qdrouterd_abort.txt > > > I'm just trying to send the CBS token to Azure (for now I have no reply and > I'll investigate in the next days) with a simple Java application through the > qpid dispatch router. > Attached you can find the wireshark pcap file (filter on tcp.port == 5672) > and a text file with qdrouterd trace. > After sending the CBS token (with no reply from Azure), there are a couple of > empty frames as heartbeat and then I "stop" the Java application from the IDE > (Eclipse). > At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but > the router crashes with following error on a failed assert : > qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion > `result == 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-295) Router aborted on assertion failed after socker closing by client
Paolo Patierno created DISPATCH-295: --- Summary: Router aborted on assertion failed after socker closing by client Key: DISPATCH-295 URL: https://issues.apache.org/jira/browse/DISPATCH-295 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.6 Reporter: Paolo Patierno Attachments: qdrouterd_abort.txt I'm just trying to send the CBS token to Azure (for now I have no reply and I'll investigate in the next days) with a simple Java application through the qpid dispatch router. Attached you can find the wireshark pcap file (filter on tcp.port == 5672) and a text file with qdrouterd trace. After sending the CBS token (with no reply from Azure), there are a couple of empty frames as heartbeat and then I "stop" the Java application from the IDE (Eclipse). At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but the router crashes (?) with following error on a failed assert : qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion `result == 0' failed. Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-295) Router aborted on assertion failed after socker closing by client
[ https://issues.apache.org/jira/browse/DISPATCH-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Patierno updated DISPATCH-295: Attachment: qdrouterd_abort.txt > Router aborted on assertion failed after socker closing by client > - > > Key: DISPATCH-295 > URL: https://issues.apache.org/jira/browse/DISPATCH-295 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Paolo Patierno > Attachments: qdrouterd_abort.txt > > > I'm just trying to send the CBS token to Azure (for now I have no reply and > I'll investigate in the next days) with a simple Java application through the > qpid dispatch router. > Attached you can find the wireshark pcap file (filter on tcp.port == 5672) > and a text file with qdrouterd trace. > After sending the CBS token (with no reply from Azure), there are a couple of > empty frames as heartbeat and then I "stop" the Java application from the IDE > (Eclipse). > At socket level it means (I see) only a simple FIN, FIN ACK, ACK sequence but > the router crashes (?) with following error on a failed assert : > qdrouterd: /qpid-dispatch/src/posix/threading.c:71: sys_mutex_lock: Assertion > `result == 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-293) The $ character can't be used inside a prefix for linkRoute
Paolo Patierno created DISPATCH-293:
---
Summary: The $ character can't be used inside a prefix for
linkRoute
Key: DISPATCH-293
URL: https://issues.apache.org/jira/browse/DISPATCH-293
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.6
Reporter: Paolo Patierno
Using a prefix like "$cbs" inside a linkRoute throws the following error at
router startup :
Mon Apr 25 15:09:24 2016 ERROR (error) Python: Exception: Cannot load
configuration file /opt/config/ex06_iothub_my.conf:
org.apache.qpid.dispatch.router.config.linkRoute: Invalid attribute reference
'$cbs/'
Mon Apr 25 15:09:24 2016 ERROR (error) Traceback (most recent call last):
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 146, in configure_dispatch
config = Config(filename)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 41, in __init__
self.load(filename, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 121, in load
self.load(f, raw_json)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
line 130, in load
self.schema.validate_all(entities)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 616, in validate_all
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 593, in validate_entity
check_singleton=check_singleton)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 453, in validate
value, lambda v: self.resolve(v, attributes), **kwargs)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 260, in validate
value = resolve(value)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 453, in
value, lambda v: self.resolve(v, attributes), **kwargs)
File
"/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
line 406, in resolve
raise ValidationError("Invalid attribute reference '%s'"%value)
Exception: Cannot load configuration file /opt/config/ex06_iothub_my.conf:
org.apache.qpid.dispatch.router.config.linkRoute: Invalid attribute reference
'$cbs/'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-239) Documentation on logging modules
[
https://issues.apache.org/jira/browse/DISPATCH-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Patierno closed DISPATCH-239.
---
Resolution: Information Provided
> Documentation on logging modules
>
>
> Key: DISPATCH-239
> URL: https://issues.apache.org/jira/browse/DISPATCH-239
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Reporter: Paolo Patierno
>Priority: Minor
>
> It could be useful to have described in the documentation what are the
> "modules" you can activate logging with "log" section inside the
> configuration file.
> I see them described in the qdrouter.json as follow :
> "log": {
> "description": "Configure logging for a particular module. You
> can use the `UPDATE` operation to change log settings while the router is
> running.",
> "extends": "configurationEntity",
> "operations": ["UPDATE"],
> "attributes": {
> "module": {
> "type":[
> "ROUTER",
> "ROUTER_HELLO",
> "ROUTER_LS",
> "ROUTER_MA",
> "MESSAGE",
> "SERVER",
> "AGENT",
> "CONTAINER",
> "CONFIG",
> "ERROR",
> "DISPATCH",
> "DEFAULT"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
Paolo Patierno created DISPATCH-240: --- Summary: qdstat : leading "/" character effects a wrong showed address Key: DISPATCH-240 URL: https://issues.apache.org/jira/browse/DISPATCH-240 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.5 Reporter: Paolo Patierno Priority: Minor Hello, it seems that the qdstat tool has some problem with leading "/" character. If we connect to an address like "/multicast/" it's showed like "ulticast"; instead removing the leading "/" the name is showed correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-241) Bias "spread" config with leading "/" on address has a "multicast" behavior
[
https://issues.apache.org/jira/browse/DISPATCH-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199965#comment-15199965
]
Paolo Patierno commented on DISPATCH-241:
-
It's possible that this strange behavior is related to the following other
issue :
https://issues.apache.org/jira/browse/DISPATCH-240
> Bias "spread" config with leading "/" on address has a "multicast" behavior
> ---
>
> Key: DISPATCH-241
> URL: https://issues.apache.org/jira/browse/DISPATCH-241
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
> Fix For: 0.6
>
>
> I have following config :
> fixedAddress {
> prefix: /spread/
> fanout: single
> bias: spread
> }
> - fanout: single means that only one consumer will receive a message
> published on /spread/ address (in a competing consumers fashion)
> - bias: spread means that the router sends message to only one consumer but
> as documentation says "in an approximately even manner". It sounds to me that
> the router tracks the consumers which receive message on that address and for
> a new message tries to send it to another consumer.
> The problem is following :
> if more consumers attach to "spread/" all works fine (only one of them
> receives message) but if they attach to "/spread/" (with leading "/") then
> all consumers receive the message like a "multicast" configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[
https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199760#comment-15199760
]
Paolo Patierno commented on DISPATCH-240:
-
Consider a configuration with something like that :
fixedAddress {
prefix: /multicast/
fanout: multiple
}
If a receiver attach to the "/multicast/" address (the one defined exactly
inside the fixedAddress section), using "qdstat -a" command you see the
following :
Router Addresses
class address phase in-proc local remote in out thru
to-proc from-proc
===
local $management Y0 0 0 00 0
0
mobile $management 0 Y0 0 1 00 1
0
local temp.Wxy5Vp+hEy 1 0 0 00 0
0
mobile ulticast/0 1 0 0 00 0
0
> qdstat : leading "/" character effects a wrong showed address
> -
>
> Key: DISPATCH-240
> URL: https://issues.apache.org/jira/browse/DISPATCH-240
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
>Priority: Minor
> Fix For: 0.6
>
>
> Hello,
> it seems that the qdstat tool has some problem with leading "/" character.
> If we connect to an address like "/multicast/" it's showed like "ulticast";
> instead removing the leading "/" the name is showed correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[ https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199853#comment-15199853 ] Paolo Patierno commented on DISPATCH-240: - I'm using the router installed from packages page in Fedora : https://qpid.apache.org/packages.html and I'm using a Java client which uses the Vert.x Proton implementation. I am going to try with the python one. > qdstat : leading "/" character effects a wrong showed address > - > > Key: DISPATCH-240 > URL: https://issues.apache.org/jira/browse/DISPATCH-240 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.6 > > > Hello, > it seems that the qdstat tool has some problem with leading "/" character. > If we connect to an address like "/multicast/" it's showed like "ulticast"; > instead removing the leading "/" the name is showed correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[
https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199945#comment-15199945
]
Paolo Patierno commented on DISPATCH-240:
-
Can you try with :
python simple_recv.py --address //multicast/ -m10
or
python simple_recv.py --address localhost//multicast/ -m10
in both cases you should have :
{noformat}
Router Addresses
class address phase in-proc local remote in out thru
to-proc from-proc
===
local $management Y0 0 0 00 0
0
mobile $management 0 Y0 0 5 00 5
0
local temp.U0e6OA7AqQ 1 0 0 00 0
0
mobile ulticast/0 1 0 0 00 0
0
{noformat}
> qdstat : leading "/" character effects a wrong showed address
> -
>
> Key: DISPATCH-240
> URL: https://issues.apache.org/jira/browse/DISPATCH-240
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.6
>
>
> Hello,
> it seems that the qdstat tool has some problem with leading "/" character.
> If we connect to an address like "/multicast/" it's showed like "ulticast";
> instead removing the leading "/" the name is showed correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[ https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199905#comment-15199905 ] Paolo Patierno commented on DISPATCH-240: - You are right we the python client it doesn't happen. I need to inspect AMQP packet from Java client and come back to you. > qdstat : leading "/" character effects a wrong showed address > - > > Key: DISPATCH-240 > URL: https://issues.apache.org/jira/browse/DISPATCH-240 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.6 > > > Hello, > it seems that the qdstat tool has some problem with leading "/" character. > If we connect to an address like "/multicast/" it's showed like "ulticast"; > instead removing the leading "/" the name is showed correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[ https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199905#comment-15199905 ] Paolo Patierno edited comment on DISPATCH-240 at 3/17/16 4:53 PM: -- You are right with the python client it doesn't happen. I need to inspect AMQP packet from Java client and come back to you. was (Author: ppatierno): You are right we the python client it doesn't happen. I need to inspect AMQP packet from Java client and come back to you. > qdstat : leading "/" character effects a wrong showed address > - > > Key: DISPATCH-240 > URL: https://issues.apache.org/jira/browse/DISPATCH-240 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.6 > > > Hello, > it seems that the qdstat tool has some problem with leading "/" character. > If we connect to an address like "/multicast/" it's showed like "ulticast"; > instead removing the leading "/" the name is showed correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-241) Bias "spread" config with leading "/" on address has a "multicast" behavior
Paolo Patierno created DISPATCH-241:
---
Summary: Bias "spread" config with leading "/" on address has a
"multicast" behavior
Key: DISPATCH-241
URL: https://issues.apache.org/jira/browse/DISPATCH-241
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 0.5
Reporter: Paolo Patierno
I have following config :
fixedAddress {
prefix: /spread/
fanout: single
bias: spread
}
- fanout: single means that only one consumer will receive a message published
on /spread/ address (in a competing consumers fashion)
- bias: spread means that the router sends message to only one consumer but as
documentation says "in an approximately even manner". It sounds to me that the
router tracks the consumers which receive message on that address and for a new
message tries to send it to another consumer.
The problem is following :
if more consumers attach to "spread/" all works fine (only one of them receives
message) but if they attach to "/spread/" (with leading "/") then all consumers
receive the message like a "multicast" configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-239) Documentation on logging modules
[
https://issues.apache.org/jira/browse/DISPATCH-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197631#comment-15197631
]
Paolo Patierno commented on DISPATCH-239:
-
Sorry I didn't see this :
http://qpid.apache.org/releases/qpid-dispatch-0.5/book/schema.html
> Documentation on logging modules
>
>
> Key: DISPATCH-239
> URL: https://issues.apache.org/jira/browse/DISPATCH-239
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Reporter: Paolo Patierno
>Priority: Minor
>
> It could be useful to have described in the documentation what are the
> "modules" you can activate logging with "log" section inside the
> configuration file.
> I see them described in the qdrouter.json as follow :
> "log": {
> "description": "Configure logging for a particular module. You
> can use the `UPDATE` operation to change log settings while the router is
> running.",
> "extends": "configurationEntity",
> "operations": ["UPDATE"],
> "attributes": {
> "module": {
> "type":[
> "ROUTER",
> "ROUTER_HELLO",
> "ROUTER_LS",
> "ROUTER_MA",
> "MESSAGE",
> "SERVER",
> "AGENT",
> "CONTAINER",
> "CONFIG",
> "ERROR",
> "DISPATCH",
> "DEFAULT"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-239) Documentation on logging modules
Paolo Patierno created DISPATCH-239:
---
Summary: Documentation on logging modules
Key: DISPATCH-239
URL: https://issues.apache.org/jira/browse/DISPATCH-239
Project: Qpid Dispatch
Issue Type: Improvement
Components: Documentation
Reporter: Paolo Patierno
Priority: Minor
It could be useful to have described in the documentation what are the
"modules" you can activate logging with "log" section inside the configuration
file.
I see them described in the qdrouter.json as follow :
"log": {
"description": "Configure logging for a particular module. You can
use the `UPDATE` operation to change log settings while the router is running.",
"extends": "configurationEntity",
"operations": ["UPDATE"],
"attributes": {
"module": {
"type":[
"ROUTER",
"ROUTER_HELLO",
"ROUTER_LS",
"ROUTER_MA",
"MESSAGE",
"SERVER",
"AGENT",
"CONTAINER",
"CONFIG",
"ERROR",
"DISPATCH",
"DEFAULT"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
