Teie kommentaarid
Hi! Um, can you give some simple steps I can use to reproduce this behavior? I executed a simple workflow like this on version 2.8.5.10 but it's not behaving exactly the way you described:
Note that if you have an 'On Error' variable the tool won't throw any errors.
- See https://warewolf.io/knowledge-base/articles/performance-monitoring/
- PRTG can be configures to monitor any performance counter in Windows, including the Warewolf ones. See https://www.paessler.com/manuals/prtg/perfcounter_custom_sensor
- Alerts are logged in the server log file when Warewolf server is running low on memory.
- PRTG can do this. See https://www.paessler.com/support/how-to/notifications-webinterface
Have you considered using mocks? The database will not be called if the database activity is replaced with a mock in the test. When the test is run the mocked activity will always output the provided data and never actually call the database.
DAL workflow works when run on it's own, but not when it is a sub-workflow?
The test still works fine though...
Screenshot taken from Warewolf 2.7.4.7
I'm not sure I understand. In my experience the test execution goes by the order the tools are executed in the workflow. For me, it always finds the correct assert/mock no matter what order the asserts/mocks are in. Can you give some example workflows and tests to demonstrate this behavior more clearly?
I have reposted this private ticket so the rest of the community can learn from it.
Customer support service by UserEcho
Try this docker command. See if http://localhost:3142/secure/.tests works after it fully starts up (might have to wait after the container has started before the server inside has started too.
docker run -d -m 4g -e SERVER_USERNAME=sai.chawan -e SERVER_PASSWORD=Unl!mit3dgUru -p 3142:3142 -p 3143:3143 warewolfserver/warewolfserver:2.8.6.16
My advice would be to start adding elements from your deployment (where it's not working) to this trivially simple example. Start by just adding all the production workflows to the container before starting it. Then try running certain lines from the deployment script that's used in the deployment where you are encountering this issue. Then run the container in a similar environment that your deployment it running. For example, as an Azure container instance or in azure kubenetes. I can't tell you exactly what these step will be, it depends on your deployment. Try to replicate the bug this way. Eventually as you bring the working example closer and closer to your non-working deployment, step by step, one of the steps will break the example. Note that step. This will be what is causing the problematic behaviour.
Otherwise I can replicate the bug for you. But I will need more information like the server log file, workflows, deployment scripts and any other relevant bits of data from your deployment.