This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Expand the 40-Character Limitation on the Size of the Launcher's Private Trigger Directory
Removing this limitation will create pod-specific private trigger directories and enable scaling up the Launcher into multiple pods/containers sharing a common application work area. This enhancement will prevent multiple Launcher from triggering off the same trigger file.
What is your industry?
How will this idea be used?
We are running the ITX 10.1.2.0 Launcher Ubuntu image in multiple pods in our production batch environment. Each pod is running a single Launcher instance and each Launcher is currently only running a single system, although both of these configurations will likely change over time (i.e. more Launchers/systems within a single pod). All Launchers use common PVCs for data persistence during pod scaling. For maximum throughput we are scaled to run 6 pods. The main "Tenant Map Handler" application receives a "request" ZIP file in a landing folder on the PVC ("/tnc/landing/polling") for which the map has a source event defined for the inbound request ZIP file. The map unzips the request, processes the request to run the tenant's map, and produces a "response" ZIP file with the output from the tenant's map execution. What we are seeing intermittently is that the response ZIP file is being created with incomplete contents, and the Tenant Map Handler map is failing due to missing files during the re-ZIPping process. I feel the issue of missing files in the response ZIP file is occurring due to multiple pods and here is why: 1. When a request ZIP file arrives in the PVC “/tnc/landing/polling” folder that one or more Launchers are watching, the ZIP file is moved into a work folder created by the Launcher named as “/tnc/landing/polling/.WTX_<port>_<podname>” (ex: ” .WTX_7002_tnc-launcher-batch-prod-9fdc94”). This is called the private Trigger Directory and the arrival of a file in this folder causes the appropriate map to be triggered. 2. These Trigger Directory folders are supposed to be uniquely named so that only the Launcher that created it will be triggered by the arrival of a trigger file (ZIP, in this case). 3. However, there appears to be a 40-character limit for this Trigger Directory folder name being imposed by ITX when it creates them. The pod name is composed of the namespace, replica set name and a unique random 5-character alphanumeric ID (ex: "tnc-launcher-batch-prod-9fdc9454c-tvxl5", where "tnc-launcher-batch-prod" is the namespace, "9fdc9454c" is the replica set name, and "tvxl5" is the unique ID assigned to the pod instance). The 40-character limit is cutting off the pod name before the 5-character unique ID when it creates the folder. 4. So, if additional pods are started and use the same replicaset name (which they usually do), we end up with several Launchers sharing a Trigger Directory and then triggering off the arrival of a single trigger file in the one Trigger Directory. Most of the work file naming generated by the Tenant Map Handler map is threadsafe, because the map prepends a unique ID to all input and output files (ex. threadID-332462201314107821). One exception to this is the name used for the temporary response ZIP file while the map adds files to it (ex. “T_B2B_275BDEBAT_B0275B00000006362056_06082023153809_TEMP_OUT.zip”). This temporary file is renamed to the final filename once it has been built so another response ZIP file delivery app will “see” the file and process it. I believe the response ZIP files are incomplete because several instances of the Tenant Map Handler map are triggered by the same request ZIP file and processing it at the same time and are all stepping on each other while building that temporary output file, or while renaming it to the final response ZIP filename. We can add the threadID to this temporary response ZIP filename, which should take care of the incomplete response ZIP files. This is an easy fix. However, the much bigger issue is how to get the Launcher to create truly unique private Trigger Directory names so that only one map instance will occur per trigger file. There doesn’t appear to be an ITX configuration setting to control this.
Do not place IBM confidential, company confidential, or personal information into any field.