I need to load alarms in bulk (2157 exactly), i’m using the sdk to add the alarms i read from a csv file but when the code reached the 1173 alarms, it blocked with the error code (413) Request Entity Too Large.
We have a suspicion that it might not be the number of alarm definitions but rather one specific alarm definition that breaks this. When you reach to the alarm definition that cause the error could you please test if you can add another instead?
The one you cannot create might be too big, or in some way incorrect in a way that makes the system think it is too big. Please test and let us know what you find.
I already tried to add other alarm same result, and if i delete one other alarm the line doesn’t block and it block at the next so it seems to be related to the number of alarms.
I want to try to reproduce the issue in our test servers here at Milestone.
Can you please share a development project that I can build and test directly? I have a feeling that with the snippets of code you already shared it is close to complete, but to ensure I use it correctly and is not missing anything I hope you will share such a test project. It could create dummy alarm definitions as long as it will make it possible for me to reproduce the issue you are seeing.
Here is my solution, you need to use the embeded AlarmesTest.csv as example and complete it with your own GUID one for a test analytic event and one GUID of a camera.
Your code must be close as I was unable to see the wrongs. I am pressed for time for doing the deep debug so I hope by sharing my code you will be able to find what it is that breaks it by comparison and single-step debugging..
(Values must be replaced. I believe i did that part right when debugging your test app.)
I must have done the first testing without ever deleting an alarm definition. Re-testing I find that RemoveAlarmDefinition always fails. If you set a breakpoint or singlestep debug is this the same you observe?
I think I will report this as a bug to Milestone Development but would like to know if my observation fits yours. Do you observe the same?
I will create a case with Milestone Support that RemoveAlarmDefinition fails if there are many alarm definitions. I will make instructions so that Development will have easy reproduction of this. Important for the case: Which version of XProtect are you using? Also, which version of the MIP SDK?
The problem is that the ConfigurationItem contains all children and everything is included in the request. This means that the request will be much larger than the default allowed request size in IIS and thus IIS refuses the request. This leads to the error we have seen if there are many Alarm Definitions on the site. We have found a workaround.
In the server hosting the Management Server service configure the IIS like this:
Open IIS Manager and pick the default website.
Start the Configuration Editor (in Management section of the window).
In the Section selector select system.webServer -security -requestFiltering
Expand the node “requestLimits”
Find the field “maxAllowedContentLength” and configure a higher value (I changed it from 30.000.000 to 500.000.000)
It is under consideration whether a design that does not include child items in this method and the big requests this leads to can be implemented. If this will be changed it is something that will come in future versions, for now please use the workaround.