I have a button in my GH canvas and when it’s pressed it does some fancy thing e.g. randomize. Compute or AppServer caches that solution when the button is pressed so randomizing is done just once if other parameters have not been changed. How can I prevent Compute/AppServer caching a solution so that randomizing is done each time the button is pressed?
Hi @jukka.maenpaa Are you using Hops to send your data to rhino.compute? If so, you can right-click on the Hops component and tell it not to cache the data on the server. Does this solve it? Or are you sending data in some other fashion?
Hi,
I forgot this one but it is still needed. I’m using Rhino Compute and App Server and not Hops. I’m not sure if AppServer is caching or Compute server or both of them.
@will @fraguada Both have more experience with the app server so I may defer this question to them. However, may I ask why you don’t want the server to cache the results? Caching will speed up the performance quite a bit (if its a big definition) and it will only return the result that is stored if all of the input parameters are the same as a previously stored definition. Even the grasshopper randomize component is generally considered “psuedo” random in that it will still return the same random number that it generated for a given seed value… so it isn’t completely random and will give you the same repeatable results even if they are “random”.
Yes, most of the time I would like to use caching but in some cases when I’m using button in UI I don’t want to use caching. By pressing a button you can write a code to increment the seed of random component (Random component is in GH file) and then caching is not wanted.
Also, in some cases I’m having C# script component in canvas (e.g. send email, download file, send file, create image file, create dwg, etc.) which is triggered by pressing a button and the script should be run every time the button is pressed. It is convenient to write that script to GH canvas since then we can easily generate new web applications from GH files and we don’t need to write the script to App Server.
I’m sorry for only just coming back to this issue. Unfortunately, we do not have a global flag that can be set which will disable caching. I have added a YouTrack issue for this so that we track this issue and get it implemented at some point in the future. However, if you’re able to send your own requests to the rhino.compute server, then you can make sure to set the cachesolve
variable to false
so that it doesn’t store the results on the server. So, here’s an example of a request that is sent to a remote server:
{
"URL": "http://URL:80/grasshopper",
"content": {
"absolutetolerance": 0.01,
"angletolerance": 1.0,
"modelunits": "Feet",
"algo": null,
"pointer": "md5_8EA4987257FE00CF8682025760012837",
"cachesolve": false,
"recursionlevel": 0,
"values": [
{
"ParamName": "myString",
"InnerTree": {
"0": [
{
"type": "System.String",
"data": "This is a made up example string"
}
]
}
}
],
"warnings": [],
"errors": []
}
}
Thanks, I’ll try it.
Hi @AndyPayne I can’t see the the status of the YouTrack issue. Is there any way now to disable caching in a remote the server?
It should be visible now, but there hasn’t been any movement on this issue. I’ll try to push it toward the top of my list.
Thank you for the shoutout @dadandroid.
@AndyPayne after some digging I have come to a conclusion that its not the result being cached, but the inputs.
I am passing a mesh to Rhino Compute on an AWS instance. The API calls are made from a python app using compute-rhino3d. I am essentially using the same grasshopper definition over and over again with changing inputs.One of these inputs needs to be a Mesh (which is the only large input, others are only a bunch of floats and integers). I followed this discussion - Compute.rhino3d.appserver partially empty output when using THREE.JS STL loader - #14 by rhinofarm to pass the STL file to Grasshopper.
Now, I noticed that while the GET GEOMETRY
component of Hops has a Delete input after solve
checkbox for them, other GET
components do not. I suspect that this b64 text string is what is cached, which piles up over multiple calls to Compute, upto a point that server is stuck at 100% memory utilization, and all calls made after this point fail after the timeout
has passed.
If you could know a workaround for this, or any advice, I would really appreciate it.
The Delete input after solve
checkbox is only used in the GH Player command. So, I don’t think that would help in this instance. I will try to prioritize this issue and will update the YT when I have more answers.