The feature is available from the user profile starting from release 2.9.1
Hi Kali, no issue about loosing an Agent's cache directory. There is no need to manually create the directory as the Agent will recreate the directory on next start up. The directory was introduced with JS-2229 for GraalVM Jobs. The GraalVM stores modules and related files to the directory and will repeat doing so if the directory is empty. If no GraalVM Jobs have been used, the directory will remain empty. You clearly did not delete anything that would not be recreated if needed. If there are no...
Hi, there is nothing you would do about this in JOC Cockpit. It's a question about your proxy configuration. Consider the fact that depending on the type of docker network in use, the containerized proxy will have to use the JOC Cockpit container's hostname/ip and inside port (bridge network). For other docker network types the docker host's hostname and JOC Cockpit container's outside port are applicable (host network).
Hi, have a look at network connections. There is one connection from JOC Cockpit to each Controller instance and there is one connection from a Controller instance to each Agent. If you operate an Agent Cluster (requires commercial license), then you find an additional layer of two Director Agents connecting to each Subagent. This means you have 1:1 connections, not a peer-to-peer network. The benefit is that each connection is clearly identified from source and target which simplifies firewall rules....
I'm sorry to say that you are hit by a bug: JOC-2312: Monitor Service - Workflow ERROR Notification functionality is broken Your original configuration using <Workflow/> without <WorkflowJob/> is correct in order to include notifications from any instructions. Due to JOC-2312 the notification is routed to the success channel instead of the error channel. The resolution is available from release 2.9.1. Branch 2.8 received its last public maintenance release with 2.8.4. Later releases in branch 2.8...
JS7 JobScheduler LTS Release 2.9.1 available
A possible root cause is your configuration of the <ObjectFragments> element: <Workflows name="FAIL"> <Workflow path="^/Z_TEST/.*$ "/> <Workflow path="/Z_SYSTEM_MAINT/"/> <Workflow path="^/BAO/.*$"/> </Workflows> should be: <Workflows name="FAIL"> <Workflow path="^/Z_TEST/.*$ "> <WorkflowJob criticality="MINOR NORMAL MAJOR CRITICAL" name=".*"/> </Workflow> <Workflow path="/Z_SYSTEM_MAINT/"> <WorkflowJob criticality="MINOR NORMAL MAJOR CRITICAL" name=".*"/> </Workflow> <Workflow path="^/BAO/.*$">...
Hi, let's simplify things: if you run a workflow with a Fail Instruction or a failing job, then you are right to assume that a notification is created. It will be present from two locations: a) the Monitor->Order Notifications view and b) from an e-mail, if Notifications are configured accordingly. Therefore, first check if a) applies. In the Monitor->Order Notifications view you will find a single entry for the error. If a) and b) applies, then you will find two entries in the Monitor->Order Notifications...