Hello, we are trying to work with urban data (100k polygons) inside grasshopper. We organize the file with ‘hops’ but we are getting this error.
@AndyPayne Any possible solution within the jumps or do we have to batch process the geometry outside the component? Would it be possible to increase the allowed body size?
At most=(empty); TreeAccess=True
Thank you very much
@little_grasshopper I guess there are a few options available to you. The first option would be to simply pare down your Grasshopper “function” so that the data you’re passing in it would be smaller. Can you break the Grasshopper file you’re using into even smaller parts (instead of one large definition) and only pass the data you need into each function? That’s probably the easiest solution, although it might not be possible in all scenarios.
The next option would be to clone the Rhino.Compute git repo and build the rhino.compute server from source. I don’t know how familiar you are with git or building projects using Visual Studio, but the process isn’t too difficult if you have a little programming experience. If you can build from source, then the line you want to modify would be line 93 in Program.cs in the Rhino.Compute project. Basically, this line sets the maximum limit for HTTP requests. The default was 30mb and we have already increased it to 52,428,800 bytes (50mb). But, obviously, you’re running up against this limit so you might need to increase this value and then build the server again. Or, you can set the MaxRequestBodySize to null and it will then allow an unlimited request body size. So, line 93 would look something like this:
options.Limits.MaxRequestBodySize = null;
Once you build the server, you’ll need to run it manually, and then make sure you enter the URL and port number in the Hops preferences section so it knows to send the request to that server and not the one that gets automatically spun up when you launch Grasshopper.
The last option would be for us to make that change and issue a new build of Hops. This is certainly doable, but I need to talk with the rest of the team to see if there are any unforeseen problems with us doing that. I will let you know if we do publish an update. I hope this helps.
wow, thanks for this quick answer, I’ll try to clone the git repository.
An option like the new timeout (v.0.15.1) would be perfect.
Thanks again and great job.
I’m thinking just setting the MaxRequestBodySize to null makes the most sense, thus eliminating the request size limit all together… but I’m just checking with a few folks before making that change.
@little_grasshopper I’ve just pushed a new version of Hops (0.15.2) which now has an environment variable which you can configure to increase the request body size limit. You can now create an environment variable called RHINO_COMPUTE_MAX_REQUEST_SIZE which sets the maximum allowed size of any HTTP request body in bytes. The default value is set to 52428800 bytes (approx. 50mb). Try downloading this latest version and then setting a larger request size limit via the environment variable and let us know if that fixes your issue.
Clever solution but what happens if someone uses a crazy large number? And to avoid typos, maybe the environment variable could be integer megabytes instead of bytes?
Well the kestrel server uses a nullable long as the data type for MaxRequestBodySize. We thought it would be best to keep the units in bytes since that’s the same unit that is passed in to the kestrel server options. Plus, since it is a long the maximum value can be set to 9223372036854775807 which is approximately 9,223,372,036,854 mb or 9,223,372 terrabytes. It’s probably safe to assume most people wont ever hit that limit. Plus, since this is the first time (that I know of) where someone has run into this issue, I think it’s also safe to assume that the vast majority of people wont ever have to deal with this issue 
.
it works! The “Request Body Too Large” error no longer appears. But another new one was shown.
CG 6002 [22:49:21 ERR] An exception occured while processing request
System.ArgumentOutOfRangeException: capacity was less than the current size.
Parameter name: requiredLength
at System.Text.StringBuilder.ExpandByABlock(Int32 minBlockCharCount)
at System.Text.StringBuilder.Append(Char* value, Int32 valueCount)
at System.Text.StringBuilder.Append(Char[] value, Int32 startIndex, Int32 charCount)
at Newtonsoft.Json.Utilities.JavaScriptUtils.WriteEscapedJavaScriptString(TextWriter writer, String s, Char delimiter, Boolean appendDelimiters, Boolean[] charEscapeFlags, StringEscapeHandling stringEscapeHandling, IArrayPool`1 bufferPool, Char[]& writeBuffer)
at Newtonsoft.Json.JsonTextWriter.WriteEscapedString(String value, Boolean quote)
at Newtonsoft.Json.JsonWriter.WriteValue(JsonWriter writer, PrimitiveTypeCode typeCode, Object value)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeDictionary(JsonWriter writer, IDictionary values, JsonDictionaryContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
at Newtonsoft.Json.JsonConvert.SerializeObjectInternal(Object value, Type type, JsonSerializer jsonSerializer)
at compute.geometry.ResthopperEndpointsModule.GrasshopperSolveHelper(Schema input, String body, Stopwatch stopwatch) in D:\BuildAgent\work\4852f584398a78e4\src\compute.geometry\ResthopperEndpoints.cs:line 116
at compute.geometry.ResthopperEndpointsModule.Grasshopper(NancyContext ctx) in D:\BuildAgent\work\4852f584398a78e4\src\compute.geometry\ResthopperEndpoints.cs:line 172
at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
at Nancy.Routing.Route.<>c__DisplayClass4.<Wrap>b__3(Object parameters, CancellationToken context)
CG 6002 [22:49:21 INF] ::1 - [2022-10-26T22:49:21.3197316+02:00] "POST /grasshopper HTTP/1.1" 500 -
[22:49:21 ERR] HTTP POST /grasshopper responded 500 in 272424.7728 ms
[22:50:04 INF] Max concurrent requests = 1
[22:51:04 INF] Max concurrent requests = 0
I can definitely batch solve it, no problem.
Thank you very much for your work.
Great!
Hello @AndyPayne and @little_grasshopper,
I can see that this issue has been marked as solved, but I have a question on a really similar topic so I thought it was better to ask here than to start a new thread.
I’ve been running a VM server for a while and I haven’t had this issue before, but now I’m trying to send multiple requests to the server at once by using promises and then I get a 413 error. Each of the request are about 8mb and I’m sending them in batches of 8 requests at a time.
My question is if you think it might be possible that the 413 response I’m getting comes from the me sending multiple concurrent requests to compute (using --childcount 8 on it), or if the size limit is only affecting each isolated request?
Thanks,
Erik
I think you’re running into an issue where the request size is too large. The default is 50mb so if you’re sending 8 request at 8mb each, then it’s likely you’re hitting this limit. However, you set an environment variable to increase this limitation. See this thread.
@AndyPayne I am getting a 413 (Payload Too Large) response from the server when calling to Compute with a size request. I am not using hops, but actually calling compute from a VM.
Would setting RHINO_COMPUTE_MAX_REQUEST_SIZE in the VM where compute is deployed through this instructions also work to increase the request size limit? Or is there anything else I need to do to increase it? Thanks!
No. I think that’s all you would need to set to increase the request limit size.
@AndyPayne I’ve just installed installed Compute in a fresh instance and after setting the following environment variables I get a 500 error with every request:
RHINO_COMPUTE_MAX_REQUEST_SIZE = 209715200
RHINO_COMPUTE_TIMEOUT = 1000000
If I delete them, the problem goes away and I can access compute again from the outside.
If it gives any hint, I have an instance that was deployed a while back with the same settings which works just fine. results from the /version endpoint of both:
working: {“rhino”:“7.34.23267.11001”,“compute”:“1.0.0.0”,“git_sha”:“a564ad7e”}
not-working: {“rhino”:“7.36.23346.16351”,“compute”:“1.0.0.0”,“git_sha”:“a564ad7e”}
Any idea what might be happening? Thanks!
Just to be clear, you used the bootstrap script for Rhino 7 is that correct?
yes, that’s correct, on both of them. Otherwise I would have Rhino 8 installed, right?
Yes, it would have installed Rhino 8 (if you used that script) but the Rhino.Compute code is also different between versions. Let me look into this.
I just created a brand new VM instance and ran the bootstrap script. I then added the two environment variables and restarted the VM. When I send any request, I get a valid response (no 500 error code). So, I can not repeat what you are seeing.
I’m working with the following:
{"rhino":"7.36.23346.16351","compute":"1.0.0.0","git_sha":"a564ad7e"}
@AndyPayne still haven’t figured it out. Just a few questions in the meantime:
is there a limit to setting that compute timeout?
Is there a way to set NO TIMEOUT?
Is there anything else that might block Compute from running as long as it takes to solve a definition?
Have you tried spinning up a new VM with the bootstrap script (rather than updating the existing VM). Again, it shouldn’t matter, I’m just trying to follow the steps that I took which did seem to work.