We are facing a peculiar situation, wherein we have quite a few adapters configured in wME4.1.1 Server. We use a single broker for the same. We have something like 42 adapters now. When we bring up the adapter config tool, in Solaris 2.8, it is taking quite somewhile to display. Each time we have to modify a setting or add a new one, it takes an eternity to do the same. We are taking care of bouncing/restarting of the adapters using the command-line option. Is there a time-effective way of configuring the adapters, other than using the memory-hog AWT based adapter_config?
Watch out! On Solaris you will eventually run out of file descriptors (c.f. ulimit command) and the adaptermonitor process will fail. At some limit of adapters (100 to 150?) you will overrun the operating system’s ability to track all the processes created. Setting your ulimit to be unlimited will help, and custom modifications can increase the total limit even more (i know that Peter Strimbu [V.P. of Integrations at Statera] has worked to modify the adaptermonitor script to increase the limit on Solaris machines).
Your options on 4.1.1 are very limited to actually modify the adapters without using the adapter_config. You can (not recommended) modify (not recommended) the adapters.cfg (not recommended) file directly, or you could (also not recommended) configure some adapters on a different machine and then merge (not recommended) the adapters.cfg file to have your modifications take effect.
To get your adapter_config tool to launch faster, you can remove unused adapters config files from the etc/adapters directory and the total load time will be reduced. I am not recommending this, but you might experiment with temporarily removing all the config files except the one for the adapter you are going to modify, launch the tool (only adapters of your remaining type will show up), make your modifications, shut the tool down, and then replace the config files.
I believe that wM is working on a remote-able adapter_config tool for an upcoming release, or, you could hire me to write one for you if you want (grin)!
Greg’s suggestion about removing the cfg files for the types adapters you are NOT using from the etc/adapters directory is a good one. I would recommend that you create a backup directory (etc/adapters/backup for instance) and move the unused .cfg files into it.
What actually happens when the adapter configuration tool starts up is that it loads all the cfg files and extracts a class name from each file. Then it uses java introspection to find out what is configurable for the adapter. Introspection is SLOW, SLOW, SLOW, which is why it takes way too long to load the tool if you have many installed adapters.
A hint to webMethods would be to load the cfg information on a need to use basis and then cache it.
We have about 1000 adapters in productions as of today.We have multiple adapter monitors which control the number of adapters under each.This overcomes the number of file descriptors in solaris.
webMethods Best Practise recommends installing adapters on the resource. For example, the JDBC adapters will run on database box, the Siebel adpater will run on Siebel box, Email adapter will run on Mail Exchange Server box, etc. Ultimately, you will end up having adapter_config tools located on different resources. And when you open each adapter_config tool, it will not be overloaded with all the adapters instead it will open only those adapters allocated to that particular resource. That way you will achieve better adapter management and quick uploading on cfg files in adapter_config.
Reconfiguring adapters: If your present implementation has all the adapters running at one single location (centralized); it’s fairly simple process of regenerating the same adapters at their resources (decentralization). This involves reconfiguration of the existing adapters with the same details.