Threads and calling Hydra plugin from a RO service

Hydra
1

Hi,

I just finished my first Hydra non-visual plugin in .NET to be called from a Delphi host. The plugin will be used to call the AWS SDK for .NET from my Delphi RO server. It is working well so far, but I have two questions before I go live with this plugin:

  1. Should I create the Module Manager in my ServerDataModule, and load the module + create the plugin instance once, when the server starts? Is this going to work ok when called from multiple RO services simultaneously, which are started in multiple different threads (as they are RO services)? Or should I create a module+plugin instance once every time the RO service is called?

  2. If my host is a Delphi VCL host, is it absolutely necessary to build with runtime packages? I had forgotten about this, and the test app is working fine without runtime packages, as well as the appserver (though I did have quite a bit of issues regarding passing arrays from Delphi to .NET but I have these regardless of whether I use runtime packages or not, and I was able to work around these issues). So I’m wondering if, when using a VCL host with a .NET non-visual plugin, it is necessary to use runtime packages? My RO/DA server has never used runtime packages, and I’m a bit wary to start using them in production, :slight_smile:.

Thanks in advance,
Arturo.

2

it is ok until you haven’t any troubles. Note: I don’t know scenario how you implemented it

For multi-platform case, as your one, delphi run-time packages aren’t required.

3

Ok, a bit more information on what I’m doing:

I have an RO server with a service called (for example) MyService and with a published operation called SendByEmail.

This operation is called by many users throughout the day, so the operation will be called many times and will most likely be called multiple times simultaneously (just like any other RO service would).

Now, in the SendByEmail operation, I use the Hydra plugin. The operation gets the data it needs and creates an object based on the custom interface created for the plugin. The data used is local to the service, so there are no threading issues here. Then, the plugin’s operation is called, I pass the custom interface to the plugin as a parameter, and receive another custom interface as a result. The plugin operation simply takes the custom interface, creates a new SendEmail object from the AWS SDK, and calls the SendEmail operation from the AWS SDK. This is also thread safe.

My question regarding thread safety is related to the Hydra Module and the plugin instance. I’ve tested it both ways:

a) Creating the Hydra Module every time the SendMail operation is called, loading the plugin and creating the plugin instance. When the operation is done, I release the instance, unload the pluging and free the hydra module

b) Create the Hydra Module once, in the ServerDataModule, and load the plugin and create the plugin instance once, and release everything only when the server is closed.

Since I don’t know what is Hydra doing when it creates that instance, I don’t know if using the same instance of the plugin in scenario “b” is thread safe. I’m guessing it is, as we are simply calling a method of the plugin with a custom interface object created within each thread (or service call). Also, from what I’ve read, this is the most common way of implementing Hydra in RO servers.

Scenario “a” seems too heavy on the resources side, as I’d probably be loading and unloading the plugin module hundreds or thousands of times throughout the day. That’s why I’d rather use scenario “b”, but since this is my first time going live with a Hydra plugin in an RO server, I’m covering all my bases by asking if this is the proper way of working with Hydra within an RO server.

Thanks!

Arturo.

4

“b” scenario is OK because your implementation of a plugin method is thread safe.

5

Excellent! Thanks!

Arturo.