Problem communicating to process outside the IIS thorugh Named Shared Memory in App Service environment

Question

This Question is regarding the sandbox environment in Azure app Service environment's shared memory communication.

We have " IBM.Data.DB2.Core.dll" to connect to DB2. We have implemented the functional level tracing to investigate in case of any issue. This application process using the IBM.Data.DB2.Core.dll sends the traces to DB2TRCD64.exe process using "Named share memory".

Issue here is DB2TRCD64.exe has to be launched from the command line. Azure app service environment is not allowing the communication through windows "named shared memory" between the DB2TRCD64.exe which is launched from command line to the application process run by IIS.

To get tracing , is there any way to achieve this type of communication ?

Does Shared memory communication is allowed from application to the process running from command prompt. ?

Answer 1

Hi @Venkatesh Babu K S ,

App Services don't have access to the console so unfortunately this isn't possible. See https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#use-of-console for more information.

Using a docker image would allow you to start processes however containers is not supported in ASEs.

Can you provide any additional information on the IBM.Data.DB2.Core.dll? Perhaps there's a different way to send the logging to a different source instead of DB2TRCD64.exe.

Answer 2

Hi,
Thanks for the reply.
IBM.Data.DB2.Core.dll is the assembly to connect to DB2 database. It internally calls the db2app64.dll a C/C++ dll.
We have implemented the logging using the shared memory(Inter process communication) technique. All the processes using the IBM.Data.DB2.Core.dll
will write to the shared memory.

We will have only exectuable, when run it will turn on the the db2trcd64.exe which will collect the
traces/log records written by the application processes and writes to the file.

In app service environment when we turn on this db2trcd64.exe from the application itself it is able to collect the traces and write to file.
But it is not able to write any log/trace records if we turn on the db2trcd64.exe from the kudu-console/commandline/powershell.

So looks like application/process running under w3wp.exe(parent process) is able to communicate using shared memory, but it is failing when process is run outside w3wp.exe.

Do you suggest any confiugration changes at ASE or anything to get this type of communicaiton working ?