The former relates to the number of connections for your outbound resource adapter. The latter relates to the number of threads used to process incoming IIOP requests (requests to your EJBs from outside the server instance process) and execution of Work requests (see J2EE CA spec). I think the description of the latter is wrong, the thread-pool has nothing to do with connections.
With both, when you have used up all connections or threads, the next request will be queued until a connection or thread comes available.
So in the case of the former, you can restrict the number of connections to your EIS, and with the latter you can restrict the number of requests that can be processed simultaneously.
Good values.. Well, in case of the former, I think it depends on how many connections your EIS allows you to open at the same time. I'd make it the same as that number. However, if you need to access this EIS from several servers (server instances) at the same time, I'd specify a lower number to prevent one server process to occupy all available connections and prevent others to connect to the EIS.
In case of the latter, it depends on how many threads you want your server process to create. Depending on your VM, OS and machine specs and cpu usage there is a sweet spot of number of threads per process where you make best usage of multi-threading. More threads than this number can slow down your application because the thread scheduler starts spending more resources on context switching and synchronization than actually processing your requests. Less threads makes requests wait for each other while they could be processed simultaneously.
Regards,
Dies
[Message sent by forum member 'dkoper' (dkoper)]
http://forums.java.net/jive/thread.jspa?messageID=268333