Understanding the Oracle Weblogic JMS infrastructure

30 Nov

I decided to create some blogposts about the wonderful world of Weblogic JMS. This due to the fact I ran into the same questions at different clients.

I will start of with this blogpost about the different Weblogic JMS components, their relation with each other and what their main configuration, logging and monitoring settings are.  The idea of this post is to provide a quick start in understanding the components of the JMS infrastructure within Oracle Weblogic.

Weblogic JMS components overview:

The following overview gives a simple idea of the relations between the JMS components in Oracle Weblogic:

Where you would like to use a Weblogic Cluster as target for JMS Modules instead of specific targeting a Managed Server. Clusters can contain 1-n Managed Servers, so even if you have a small Weblogic domain you can create an environment which already uses clustering and is ready for future domain expansion.

Persistent Stores:

  • 2 types: filestore (disc) and JDBCstore (database)
  • Target: 1 Managed Server
  • Some situation require dedicated persistent stores due to security/audit regulations of the information        stored. Keep this in mind in your JMS infra design.
  • Important configuration:
    • location (folder on disc) or connection (database)
    • maximum file size of persistent filestore (default = 1.342.177.280 bytes)
    • send policy: First-In-First-Out as default, but preemptive allows more speed for huge small messages
    • write-policy: Important for shared storage solutions
  • Monitoring:
    • Statistics (create/read counts, buffers)
    • Active filestore connections (from JMS Server)

JMS Servers:

  • Target: 1 Managed Server
  • Connected to a Persistent Store
  • Important configuration:
    • Threshholds bytes/messages: becomes “ARMED” and instructs producers to slow dow, default disabled !!!!
    • Maximum bytes/messages: maximum for incoming messages, Oracle recommends total amount of system memory available after accounting rest of application load. Default disabled !!!!
    • Maximum individual Message Size: Default is 2.147.483.647 !!!! which is huge and in most of my client cases totally unrealistic. Prevent future issues and tune this down.
  • Monitoring en Logging:
    • Configuratie where JMS logging is located, not WHAT to log
    • Monitoring of messages ( total, pending, current) and size

JMS Module:

  • Target: Preferred to Weblogic Cluster(s) for scaling, but also possible to single or multiple managed server(s)
  • Owner of 0-n SubDeployments
  • Contains artifacts such as queues, topics and connections factories (CF)
  • Important configuration:
    • Security, users and policies (specific hours, etc)
    • Location for JMS Connection Factory used by client connecting

JMS Modules – SubDeployments

  • Configured in the JMS Module
  • Target: Weblogic Cluster
  • Allows grouping of queues and topics

JMS Module – Queue/Topic

  • Most commonly used JMS artifacts
  • Configured in the JMS Module
  • Configured in the SubDeployment (preferred)
  • Important configuration (there is much much more):
    • Java Naming and Directory Interface (JNDI) which provides a lookup facility
    • Individual threshold and quotas
    • Individual override for time-to-live, priority and delivery mode (persistency)
    • Failure options: amount of redelivery, redirect to error queue/topic or discard
    • Monitoring en Logging:
      • Defines WHAT to log, full body/header or specific header fields as CorrelationID, MessageID.
      • Amount of consumers/subscribers

My personal Weblogic JMS best practices:

  • Certain Oracle products, like the Oracle SOA suite, come with their own JMS artifacts like modules, queues, topics and connection factories (CF). Just leave them and do NOT create your own queues/topics/etc in these modules and “abuse” their Persistant Stores. They are not yours ;)

  • Use queues for point-to-point and topics for publish/subscribe. If you design a publish/subscribe point-to-point connection try to use a topic for future 1-n delivery. If not possible, start with a queue and think about your JNDI naming so you can always change the configuration from queue to topic in the future.
  • If you need queues/topics that are JTA user-transaction aware you need a XA Connection Factory. Make sure your timeout (default = 3600 seconds) is enough for any long running transactions.
  • When you don’t configure the Persistent FileStore location, it will create a %filestore_name% folder in your weblogic %domain% folder. If no complex shared storage solutions are used, I prefer to  create a /filestores/ folder in the domain root and target all filestores there (example: ../filestores/myFilestoreA/) to prevent a mess in your %domain% folder. Make sure that the folder exists, to prevent errors like:  Caused by: [Store:280044] The file store directory “….\rbx_dev_domain\filestores” does not exist
  • Use Distributed Queues and Distributed Topics to make use of the scalability Weblogic clustering technology provides
  • Think about your naming convention for both internal and external (JNDI)
  • Tune your Weblogic JMS instance by defining quotas, thresholds and sizes. See this blogpost from Darrel for more information.

As I wrote before, I am not all-knowing, so if you have different insights or can add useful information to this post please do.


1 Comment

Posted by on 30-11-2011 in Weblogic


Tags: ,

One response to “Understanding the Oracle Weblogic JMS infrastructure

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: