Bug 584805 - Unable to retrieve arguments from event raised by ruby client
Summary: Unable to retrieve arguments from event raised by ruby client
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-qmf
Version: Development
Hardware: All
OS: Linux
Target Milestone: 1.3
: ---
Assignee: Ken Giusti
QA Contact: Jan Sarenik
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-22 13:09 UTC by Robert Rati
Modified: 2011-08-12 16:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:
kgiusti: needinfo-

Attachments (Terms of Use)
example: create an event w/o any arguments. (3.53 KB, patch)
2010-05-17 15:09 UTC, Ken Giusti
no flags Details | Diff
testcase (1.05 KB, application/x-gzip)
2010-05-25 21:15 UTC, Ken Giusti
no flags Details
Updated test (1.24 KB, application/x-gzip)
2010-05-26 08:35 UTC, Jan Sarenik
no flags Details

Description Robert Rati 2010-04-22 13:09:03 UTC
Description of problem:
I've got a ruby agent that is raising an event with arguments, and a python console that is listening for events.  The python client receives the events, but I am unable to retrieve the arguments from the event via getArguments().

xml for the event:

   <arg name="nodelist" type="map"/>
   <arg name="nodelist_str" type="lstr"/>

<event name="NewConfigEvent" sev="alert" args="nodelist,nodelist_str"/>

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Ken Giusti 2010-04-22 14:44:34 UTC
Hi Robert,

Would it be possible to have the ruby agent dump the arguments just prior to raising the event?   I'd especially like to see the contents of the nodelist map that is being put in the event.

I suspect that the problem may be dependent on the content of the map - I've got a test case that passes a map containing strings and integer types from a ruby agent to a python console successfully.  I'll add more types, but I'd like to repro the problem using exactly the map that you are seeing trigger the bug.



Comment 2 Ken Giusti 2010-04-23 15:34:54 UTC
Problem exists in the Ruby and Python wrapped implementation (I was trying to repro the problem using the native python console - does not apply).

Upstream bug:


Comment 3 Ken Giusti 2010-04-23 20:29:29 UTC
Have implemented the Ruby wrapper side:

Committed revision 937506

Python wrapper is pending....

Comment 4 Ken Giusti 2010-04-29 14:59:23 UTC
Reporter still experiencing issue after receiving fix.

Bumping priority.

Comment 5 Ken Giusti 2010-04-29 22:15:14 UTC
Update: we've determined the reason for the failure.   The agent application is dynamically defining the event's schema, registering it, then immediately raising an instance of the new event.

The console ends up receiving the event, but has not yet received an updating containing the event's schema definition.  Therefore, the console cannot decode the event's arguments.

On further investigation, it seems the agent _never_ notifies the console of the new schema definition.

A possible work around: have the agent application pre-define all the event schemas prior to connecting the agent to the broker (via agent.set_connection), if possible.

I'm investigating the schema update issue.

Comment 6 Ken Giusti 2010-04-30 17:34:02 UTC

The above patch causes the Agent to send indications for newly-defined schema.  The patch does _not_ solve the issue, but it is a necessary part of the solution.

Comment 7 Ken Giusti 2010-05-03 14:11:47 UTC
Additional work needed to solve this issue:

The console libraries need to be modified to correctly deal with the scenario where a event with an unknown schema is received.  A possible solution would be to have the console cache the event and send a request for the unknown schema to the broker.   Once the schema is received, the console can then pass the cached event to the application.  The event should be dropped if the schema cannot be retrieved. 

Both the C++ console (qmfengine) and the pure python console will need to be updated.

Comment 8 Ken Giusti 2010-05-11 12:48:03 UTC
Workaround suggested above does not resolve the problem for Grid.  Identified a related issue that prevented events with no arguments from being decoded correctly.  Patched: http://svn.apache.org/viewvc?view=revision&revision=942861

With this last fix, the workaround will unblock grid.

Comment 9 Frantisek Reznicek 2010-05-17 09:17:48 UTC
There are few unclear points:
a] It is not clear how to raise the above described event type.
   Is there any example/snipped I can use for ruby/python/c++ testing of this BZ?
b] C++ / python console libraries should be updated as noted in comment #7
   Was this done? At which revision?
   None of above links show python console update?


Comment 10 Ken Giusti 2010-05-17 15:03:27 UTC
a] You need to define an event schema that does not have any arguments defined.  I don't have a working example, but I will attach a diff against the existing qmf/cpp/bindings/qmf/tests/python_agent.py that will give you an example how to define and raise such an event.   [note: Since the consoles in the testbed expect the event to contain arguments, applying the patch will cause the tests to fail].

b] There have been no patches against the console libraries. It has been decided that this bug will be addressed in the v2 release of qmf.  Pre v2 releases should use the workaround defined above.

Comment 11 Ken Giusti 2010-05-17 15:09:34 UTC
Created attachment 414577 [details]
example: create an event w/o any arguments.

Comment 13 Ken Giusti 2010-05-25 21:15:51 UTC
Created attachment 416561 [details]

Comment 15 Jan Sarenik 2010-05-26 08:35:52 UTC
Created attachment 416714 [details]
Updated test

Reproduced on

Verified on

Comment 16 Jan Sarenik 2010-05-26 09:03:44 UTC
Verified also on i386 RHEL5.5, the same qpid build as above.

Comment 17 Jan Sarenik 2010-05-26 09:06:16 UTC
There is no ruby-qmf package on RHEL4 --> VERIFIED.

Note You need to log in before you can comment on or make changes to this bug.