[ 
https://issues.apache.org/jira/browse/DISPATCH-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837274#comment-16837274
 ] 

ASF GitHub Bot commented on DISPATCH-974:
-----------------------------------------

kgiusti commented on pull request #503: DISPATCH-974 - Added code to qdstat and 
qdmanage clients to repeatedl…
URL: https://github.com/apache/qpid-dispatch/pull/503#discussion_r282879722
 
 

 ##########
 File path: python/qpid_dispatch/management/client.py
 ##########
 @@ -225,12 +225,61 @@ def query(self, type=None, attribute_names=None, 
offset=None, count=None):
         @keyword count: A count of the maximum number of results to return.
         @return: A L{QueryResponse}
         """
-        request = self.node_request(
-            {u'attributeNames': attribute_names or []},
-            operation=u'QUERY', entityType=type, offset=offset, count=count)
 
-        response = self.call(request)
-        return Node.QueryResponse(self, response.body[u'attributeNames'], 
response.body[u'results'])
+        # There is a bug in proton (PROTON-1846) wherein we cannot ask for
+        # too many rows. So, as a safety we are going to ask only for
+        # MAX_ALLOWED_COUNT_PER_REQUEST. Since this is used by both qdstat
+        # and qdmanage, we have determined that the optimal value for
+        # MAX_ALLOWED_COUNT_PER_REQUEST is 700
+        MAX_ALLOWED_COUNT_PER_REQUEST = 700
+
+        response_results = []
+        response_attr_names = []
+        if offset is None:
+            offset = 0
+
+        if count is None:
+            # count has not been specified. For each request the
+            # maximum number of rows we can get without proton
+            # failing is MAX_ALLOWED_COUNT_PER_REQUEST
+            request_count = MAX_ALLOWED_COUNT_PER_REQUEST
+        else:
+            if count > MAX_ALLOWED_COUNT_PER_REQUEST:
+                request_count = MAX_ALLOWED_COUNT_PER_REQUEST
+            else:
+                request_count = count
+
+        while True:
+
+            request = self.node_request(
+                {u'attributeNames': attribute_names or []},
+                operation=u'QUERY', entityType=type, offset=offset,
+                count=request_count)
+
+            response = self.call(request)
+
+            if not response_attr_names:
+                response_attr_names += response.body[u'attributeNames']
+
+            response_results += response.body[u'results']
 
 Review comment:
   You might consider using a map indexed by entity id here as a way to filter 
out duplicates.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


> Getting connections via the router management protocol causes AMQP framing 
> errors
> ---------------------------------------------------------------------------------
>
>                 Key: DISPATCH-974
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-974
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Management Agent
>    Affects Versions: 1.0.1
>            Reporter: Marcel Meulemans
>            Assignee: Ganesh Murthy
>            Priority: Major
>         Attachments: qdrouter-frame-errors.pcapng.gz
>
>
> I am running a standalone router with 5000 clients connected. When I try to 
> get all connections via qdstat (qdstat --limit 5000 -c) something goes wrong 
> (seems to be a framing error). The output from qdstat is:
> {{ MessageException: [-10]: data error: (null)}}
> The problems seems to somehow be related to result size because when I set 
> the limit to less I get the list of connections as expected. In my situation 
> the critical limit is 3447 (i.e. 3447 result in the expected list of 
> connections, 3448 result in the error above). It does not seem to be frame 
> size related because getting 3447 connection is already spread over transfer 
> frames (256182, 256512 and 159399 bytes).
> The error is not qdstat related because using some plain proton code to 
> create a management query results in the same problem. Ultimately the call to 
> pn_message_decode with data receive from the router fails (also wireshark can 
> not decode the final frame).
> I have attached a wireshark dump to the qdstat session with the router 
> ([^qdrouter-frame-errors.pcapng.gz]). The logs of the router (at info level) 
> contain no further information.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to