I'm not sure why you'd SAVE without any changes.
But anyway , this would cause the current modular input instance to end (hard process kill) and a new one to start up.
So any connections to your messaging server would end and new ones would be established.
I can not ignore a SAVE with "no changes" in the modular input code , this would be functionality required in core Splunk.
Regarding Client ID "DEV-SPLUNK" is already in use , this may well be vendor specific behaviour , Webmethods in this case. JMS is just an API that abstracts away many different underlying messaging platforms that have a JMS provider implementation.
This probably addresses the previous point , but regarding why Webmethods still sees an active connection/holds onto a dead connection even when the JMS Mod Input process terminates , hard to answer , may be Webmethods specific connection handling functionality ? Other messaging platforms seem to terminate the connection in this scenario.
I would suggest that if Webmethods removed the connection handle when the Mod Input terminates , this would probably address the core issue at hand regarding successful reconnection.
Regarding "...the client has advised they are unable to have two simultaneous JMS inputs...." , many usesr of this Mod Input have multiple inputs defined and running concurrently , so again , without knowing the exact deployment or seeing any config files , I can only suggest that this might be some constraint in the WebMethods setup ?
... View more