Hi,
I'm new to R and R.Net and I'm approaching both with one single objective: from our web-app, call some relatively simple R commands, get some graphs out of it and send them to the client.
More in detail, the web-app is a Silverlight application that uses CSLA for the Business Logic layer, it's public-facing and needs to remain reliable.
I've tried to figure out what the issues with thread safety are and whether they have been resolved, and rapidly got lost. There are lots of warnings against trying to use R (and/or R.Net) from an ASP application, and some reassuring news in both the ISSUES section and elsewhere. So, all in all, I'm uncertain of the current situation.
Hence, the short question is: would it be safe to use R.Net with ASP/IIS?
We have plenty of concurrent users, but I think we can afford allowing just one thread to process calls to R, that is: user A calls some R package, while this is running, user B will be able to trigger another call, but this second call will only execute after the first is finished. It's not ideal, but we can afford to write code to support this strategy and see how it goes.
What we can't afford is restricting the whole application to run in a single thread, "just because" otherwise calls to R would fail. The way I understand ASP/.Net/IIS is that IIS will handle threads and may create and dispose them as requests come in, what I don't understand is whether this behaviour will be a problem while calling R via R.Net (and/or calling R in other ways such as D-Com).
I imagine the current project members do understand the current limitations, and I'm happy to help testing in case we do expect our scenario to be fully supported. Otherwise, I'm afraid that I'll find it difficult to justify spending testing time on something that might never work for us.
In all cases, thanks for this very interesting project.
Sergio
I'm new to R and R.Net and I'm approaching both with one single objective: from our web-app, call some relatively simple R commands, get some graphs out of it and send them to the client.
More in detail, the web-app is a Silverlight application that uses CSLA for the Business Logic layer, it's public-facing and needs to remain reliable.
I've tried to figure out what the issues with thread safety are and whether they have been resolved, and rapidly got lost. There are lots of warnings against trying to use R (and/or R.Net) from an ASP application, and some reassuring news in both the ISSUES section and elsewhere. So, all in all, I'm uncertain of the current situation.
Hence, the short question is: would it be safe to use R.Net with ASP/IIS?
We have plenty of concurrent users, but I think we can afford allowing just one thread to process calls to R, that is: user A calls some R package, while this is running, user B will be able to trigger another call, but this second call will only execute after the first is finished. It's not ideal, but we can afford to write code to support this strategy and see how it goes.
What we can't afford is restricting the whole application to run in a single thread, "just because" otherwise calls to R would fail. The way I understand ASP/.Net/IIS is that IIS will handle threads and may create and dispose them as requests come in, what I don't understand is whether this behaviour will be a problem while calling R via R.Net (and/or calling R in other ways such as D-Com).
I imagine the current project members do understand the current limitations, and I'm happy to help testing in case we do expect our scenario to be fully supported. Otherwise, I'm afraid that I'll find it difficult to justify spending testing time on something that might never work for us.
In all cases, thanks for this very interesting project.
Sergio