Taritsyn / JavaScriptEngineSwitcher

JavaScript Engine Switcher determines unified interface for access to the basic features of popular JavaScript engines. This library allows you to quickly and easily switch to using of another JavaScript engine.
Apache License 2.0
439 stars 49 forks source link

Node options #84

Closed abusalaa7 closed 4 years ago

abusalaa7 commented 4 years ago

The node js library has a lot of settings that can be passed to it via its constructor. It seems the adapter in JavaScriptEngineSwitcher doesn't have a way of passing these options. For example: the concurrency option that allows spawning multiple node instances and load balance the calls to them. https://github.com/JeringTech/Javascript.NodeJS

Is there a way to to do that now or are there any plans to add that option soon?

Taritsyn commented 4 years ago

Hello, Ahmed!

It seems the adapter in JavaScriptEngineSwitcher doesn't have a way of passing these options.

Node JS service must be configured by using the API of Jering.Javascript.NodeJS library. I have added the “Node > Runtime settings” subsection to documentation.

For example: the concurrency option that allows spawning multiple node instances and load balance the calls to them.

Using of this option will lead to errors in the JavaScript Engine Switcher, because each engine has its own state, which must be saved between calls.

abusalaa7 commented 4 years ago

Thanks for clarifying and updating the documentation. I think it will be helpful to list the options that are not supported in the documentation too, including the concurrency option. Although I don't fully understand why that would be an issue. The singleton instance of the node service should be handling that load balancing on it's own. JavaScriptEngineSwitcher won't create multiple engines, the static service will, so I'm assuming it has its own way of saving the state.

Taritsyn commented 4 years ago

JavaScriptEngineSwitcher won't create multiple engines, the static service will, so I'm assuming it has its own way of saving the state.

The fact of matter is that the service does not store state. Each call is made independently.

The singleton instance of the node service should be handling that load balancing on it's own.

In principle, engine cannot limit itself to a single call of the service. In this mode, each call of the service can be made in different processes, which does not allow us to store a state in the process.