Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

RDEP - Increasing the max NbrOfEvents value - urgent!

We are using the RDEP subscription to retrieve events from the sensors. One problem is we currently have 2.6 millions events (in our test environment) per day and it seems that the maxNbrofEvents of the RDEP subscription request is 500. So, it takes forever just to finish getting a whole day data. According the RDEP specification, it's the server that set the limit. My question is where can I find the setting, so I can increase it.

Thanks!

3 REPLIES
Cisco Employee

Re: RDEP - Increasing the max NbrOfEvents value - urgent!

This setting is not user modifiable.

This was hardcoded so as to limit the memory consumption of the eventServer and not affect the rest of the sensor.

Is your RDEP client coming in at the end of the day to get all of the previous days alarms?

If so then consider keeping your RDEP client constantly running so it continously throughout the day executes get requests to get the days events.

At 2.6 million events a day this averages out to about 31 alarms a second. With a maxNbrofEvents of 500 your client and the sensor's server should be able to keep up if the get request can be received and answered every 16 seconds (500events / 31eventspersecond = 16seconds)

New Member

Re: RDEP - Increasing the max NbrOfEvents value - urgent!

We currently have a cron job that send the request every minute. So, I guess we just need to put it in a while loop that run continuously instead. Do you think this will cause problem? Thanks for the info!

New Member

Re: RDEP - Increasing the max NbrOfEvents value - urgent!

A while loop is a great idea. In fact, that is how we designed RDEP to work.

If you open a subscription, a get on a subscription will block indefinitely until one or more events are ready to retrieve. What this means is that the subscriber is stopped waiting for the response, and is utilizing a minimum amount of resources on the host.

Problems enter into the picture when the subscriber is written using a HTTP library that has a problem with indefinitely-blocked requests. For example, most Java libraries will give up if no response is received within about 75 seconds. Our recommendation is to try it with indefinite blocking, and only if it fails should you use the workarounds. These are documented in the RDEP specification.

114
Views
0
Helpful
3
Replies
CreatePlease to create content