Bug 584805

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.

thanks,

-K

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:

https://issues.apache.org/jira/browse/QPID-2546

Have implemented the Ruby wrapper side:

Committed revision 937506

Python wrapper is pending....

Reporter still experiencing issue after receiving fix.

Bumping priority.

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.

http://svn.apache.org/viewvc?view=revision&revision=939736

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.

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.

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.

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?

Raising NEEDINFO.

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.

Created attachment 414577 [details]
example: create an event w/o any arguments.

Created attachment 416561 [details]
testcase

Created attachment 416714 [details]
Updated test

Reproduced on
  ruby-qmf-0.7.929717-1.el5
  qpid-cpp-server-0.7.929717-1.el5

Verified on
  ruby-qmf-0.7.946106-1.el5
  qpid-cpp-server-0.7.946106-1.el5

Verified also on i386 RHEL5.5, the same qpid build as above.

There is no ruby-qmf package on RHEL4 --> VERIFIED.