The listener makes drones do its dirty work for bounced "register" messages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenSRF |
Fix Released
|
Medium
|
Unassigned |
Bug Description
When an opensrf service starts up, one of the first things it does is go out and register with all the routers it finds in its config file for which it is a listed service (more or less). If any secondary routers to which it wants to register are not there at the moment, it will get its registration message reflected back to it. That is the normal way of things in XMPP-land.
Now, because the listener is trying to be as slim, fast, and dumb as possible, it simply passes that reflected message down to a waiting drone to handle. This is silly and wasteful, and fills the logs with /very/ angry looking noise.
Luckily, the fix should be simple. The Listener can look at the first few bytes that i plans to pass down to the drone, and if it starts with exactly "register" then the message can be dropped and ignored.
Changed in opensrf: | |
status: | Fix Committed → Fix Released |
Fix pushed to:
http:// git.evergreen- ils.org/ ?p=working/ OpenSRF. git;a=shortlog; h=refs/ heads/user/ berick/ lp1341687- drop-reflected- xmpp-messages
While researching this, I realized that this was a good opportunity to do something which should have been done long ago: have the listeners drop bounced messages. There is partial support for this in the drones already, but doesn't always work -- in the Perl code, some important error data is not passed down to the drone, so it's lost -- but dropping it in the Listener, as Mike suggests, is more efficient. It also will reduce and possibly completely avoid the confounding "No AppSession object returned from server_build()" messages sometimes seen in the Perl code.
To test the patch, add a bogus router to <opensrf> section of opensrf_core.xml. The listeners will attempt to register and will get a bounced message. The error is logged at INFO, since it may be important information, but not at WARN/ERR since it may not be an error condition in some cases.