1. Create a custom store on each WebLogic server that will host a JMS server. If there's already a custom store on a WebLogic server, you can skip this step as its usually more convenient and more performant for services to share a store. (Why use a custom store? Custom stores provide more flexibility in tuning and administration. In addition, the default file store is not migratable -- only custom stores are migratable.)
2. In a cluster, target each store to its host server's "default migratable target". If you have decided not to use a cluster, target each store directly to its host server. Migratable targets enable restart-in-place options on a store failure, and also enable service migration options.
It is recommended to always target to migratable targets when available (instead of direct server targets). Migratable targets are compatible with the whole server migration option, and usually should be configured even when whole server migration is the primary fail-over option.
3. Configure a JMS server on each WebLogic server. Configure the JMS server to reference the store that was created in step 1. Target the JMS server to the same target that was used for the store. Multiple JMS servers can reference the same store.
4. Configure message count quotas on each JMS server. There is no default quota, so configuring one helps protect against out-of-memory conditions. Rule of thumb:
conservatively assume that each message consumes 512 bytes of memory even if it is paged out.
5. Although JMS paging is enabled by default, verify that the default behavior is valid for your environment.
No comments:
Post a Comment