Closed GoogleCodeExporter closed 9 years ago
Thanks for letting me know about the larger packet size
looking at change log
http://nagios.svn.sourceforge.net/viewvc/nagios/nsca/trunk/Changelog?revision=18
76&view=markup
seems like it supports message size of 4000 chars. Is this correct or is it
indeed 4096 chars?
Original comment by rajneeshpatel
on 22 Feb 2012 at 11:56
Just checked source code on
http://nagios.svn.sourceforge.net/viewvc/nagios/nsca/trunk/include/common.h?revi
sion=1911&view=markup
Seems like it is 4096 as per #define MAX_PLUGINOUTPUT_LENGTH 4096
Going to have a think about how we can differentiate/switch to support larger
plugin output
Original comment by rajneeshpatel
on 22 Feb 2012 at 12:12
I also checked with the source code of nsca. I would just force people to use
the latest version of nsca. Version 2.7.2 is the first version that wouldn't
support the long messages and this was released in 2007.
You could add useShortMessage(bool) to NagiosSettings and also
withShortMessage(bool) in to SettingsBuilder. The PassiveCheckSender could then
call either a message to set the flag for the PassiveCheckBytesBuilder or you
change the constructor of PassiveCheckBytesBuilder to take NagiosSettings as
parameter (the latter would be better I think...)
Original comment by Matthia...@gmail.com
on 22 Feb 2012 at 10:24
OK, initial thought is to create a LargeMessagePayload class as a type of
MessagePayload
Then, push the max message size in number of chars into both of these so they
encapsulate this information and remove the PLUGIN_OUTPUT_SIZE from the
PassiveCheckBytesBuilder. The PassiveCheckBytesBuilder will then ask the
message payload whats the max number of chars and use this.
So the behaviour will be as follows
- If you use the MessagePayload and have a message longer than 512 chars, it
will be truncated to 512 chars as it is today
- If you use the LargeMessagePayload and have a message longer than 4096 chars,
it will be truncated to 4096 chars
Hopefully, this way, people using pre 2.9.1 versions of NSCA dont need to
change anything
For those who want to leverage the larger message size, all they need to do is
use LargeMessagePayload
Any thoughts?
Original comment by rajneeshpatel
on 24 Feb 2012 at 8:31
Tried to implement as above but resulted in a lot of extra classes being
created.
Therefore, instead, to switch on support for large messages, use
MessagePayloadBuilder withSupportForLargeMessages() method as shown below
MessagePayload messagePayload = new MessagePayloadBuilder()
.withSupportForLargeMessages()
.withHostname("localhost")
.withLevel(Level.CRITICAL)
.withServiceName("test service")
.withMessage("test message")
.create();
Zips and tars for 2.1-RC1 available from downloads page if you want to give
this a try and see if it works for you
Original comment by rajneeshpatel
on 24 Feb 2012 at 2:31
[deleted comment]
[deleted comment]
[deleted comment]
unable to upload so will do later, source checked in though
Original comment by rajneeshpatel
on 24 Feb 2012 at 2:36
right, thought about this some more and think this does need to be on
NagiosSettings as you suggested earlier.
You typically create settings once where with the switch on the
MessagePayloadBuilder, you would need to do this for every point you construct
messages
Putting on NagiosSettings and NagiosSettingsBuilder instead
Original comment by rajneeshpatel
on 24 Feb 2012 at 2:57
Source code committed, withLargeMessageSupportEnabled() added to
NagiosSettingsBuilder and enableLargeMessageSupport() added to NagiosSettings
NagiosSettings nagiosSettings = new NagiosSettingsBuilder()
.withLargeMessageSupportEnabled()
.withNagiosHost(HOSTNAME)
.withPassword(PASSWORD)
.withEncryption(XOR)
.create();
Will upload 2.1-RC1 to downloads this evening
Original comment by rajneeshpatel
on 24 Feb 2012 at 4:29
2.1 RC1 Zip and TGZ available in download area
Original comment by rajneeshpatel
on 26 Feb 2012 at 8:18
Will test it. Thank you. I would prefer a shorter method name though than
withLargeMessageSupportEnabled. Something like withLongMessage. Another
suggestion... What you think about having a boolean parameter for that? Like
"withLongMessage(false)". This would result in a code which is backward
compatible, and you could change the default over time to long messages.
Original comment by Matthia...@gmail.com
on 26 Feb 2012 at 10:26
Original issue reported on code.google.com by
Matthia...@gmail.com
on 22 Feb 2012 at 5:51Attachments: