Weblogic

##############################################################################################

Using NodeManager to Start ManagedServers.

 

Use your nodemanager to take care of the Admin and Managed serves while rebooting the VMs

 

 

##############################################################################################

JMS Persistence Strategy

 JMS Persistent Store types

There are two choices for the persistence of JMS messages, a JDBC store or a File store. Although both guarantee delivery, there are advantages and disadvantages to each type of store.

 

File Store

                The file based persistent store is the easiest type of persistent store to configure. Weblogic simply creates a file at a specified location on disk and writes messages to that file. The default size of this file is 1,049,088 bytes. In the event that the Weblogic instance goes down while there are still messages in the file store, those messages will be processed when the instance is restarted. In the past we have had Weblogic instances crash when the application logs space becomes full.

Average # of messages per minute * max expected down time in minutes.

     Advantages of File based Persistence

  • Easy to configure
  • No dependencies on external resources

Disadvantages of File based Persistence

  • No control over file size. File grows but never shrinks even after messages are processed.
  • If entire server goes down, there is no way to get the file to another server for processing

 

Configuration details

  • Name
  • Directory where file store will reside
  • Logical name (used in clustered environment)
  • Synchronous write policy

o    Disabled

  • Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This policy is the fastest, but the least reliable (that is, transactionally safe). It can be more than 100 times faster than the other policies, but power outages or operating system failures can cause lost and/or duplicate messages.

o    Cache-Flush

  • Transactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.

o    Direct-Write (Default)

  • File store writes are written directly to disk. This policy is supported on Solaris, HP-UX, and Windows. On Windows systems, this option generally performs faster than the Cache-Flush option writes.

 

 

JDBC Store

                A JDBC store uses a JDBC Data Source to persist messages and thus requires table space in a database. Once a data source and underlying connection pool are created, a persistent store can be defined using the new data source. If the required tables for the persistent store do not exist, Weblogic will automatically attempt to create them using DDL files contained within the Weblogic.jar file. In this investigation, we simply created an oracle connection pool and then created a persistence store using that pool. Weblogic automatically created the required tables in that database and began using them. In a production environment this will probably not be allowed. Instead, DDL files from the Weblogic JAR file can be provided to the DBAs to pre-create the tables for the persistent store. It should be noted however that if more than one application intends to share the same database, each will need their own set of tables since JMS servers cannot share persistent stores. The Weblogic console facilitates this by providing a prefix that is prepended to the table name to make it unique.

 

Advantages of JDBC based persistence

  • Faster than file store persistence
  • Data accessible anywhere on the network allowing for easy failover
  • Records are removed from the database as they are processed

Disadvantages of JDBC based persistence

  • Requires 1 table per JMS server. JMS servers cannot share the same table or corruption will occur
  • Special configuration options must be observed if more than one JMS server will share the same database, mainly table prefix
  • If database becomes unavailable for any reason, the Weblogic instance must be restarted.

 

Configuration details

  • Name- The name of the persistent store
  • Target  – The Weblogic managed instance this store will belong to
  • Data Source – The data source to use for persisting data. Support databases are: DB2, Oracle, MSSQL, Informix, Pointbase and Sybase
  • Prefix Name

o    The prefix for the JDBC store’s database table (WLStore), in the following format: [[[catalog.]schema.]prefix]. Each period symbol in the [[catalog.]schema.]prefix format is significant, where schema generally corresponds to username in many databases. When no prefix is specified, the JDBC store table name is simply WLStore and the database implicitly determines the schema according to the JDBC connection’s user. As a best practice, you should always configure a prefix for the JDBC WLStore table name. For specific guidelines about using JDBC store prefixes, refer to the “Using the WebLogic Store” section of Designing and Configuring WebLogic Server Environments” on http://e-docs.bea.com/wls/docs90/config_wls/store.html#JDBCStorePrefixes

  • Logical Name (used in clustered environments only )
  • Create Table from DDL File

o    This field is ignored when the JDBC store’s backing table, WLStore, already exists.

o    If a DDL file is not specified and the JDBC store detects that a backing table doesn’t already exist, the JDBC store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor. These preconfigured files are located in the weblogic.jar file in the weblogic/store/io/jdbc/ddl directory.

o    If a DDL file is specified and the JDBC store detects that a backing table doesn’t already exist, then the JDBC store searches for the DDL file in the file path first, and then if the file is not found, it searches for it in the CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store’s database table. If the DDL file is not found and the backing table doesn’t already exist, the JDBC store will fail to initialize and hence the JMS server will be in a failed state when the instance comes up.

  • Deletes Per Batch Maximum

o    Maximum number of table rows that are deleted per database call

o    Default is 20

o    Current recommended value: 20

  • Inserts Per Batch Maximum

o    The maximum number of table rows that are inserted per database call

o    Default is 20

o    Current recommended value: 20

  • Deletes Per Statement Maximum

o    The maximum number of table rows that are deleted per database call

o    Default is 20

o    Current recommended value 20

 

 

Requeueing and paging

Some applications that use JMS messaging, may want to requeue a message multiple times if it cannot be delivered or processed. As of this document there appears to be a bug in Weblogic 9.1 that prevents messages from being requeued if an instance is configured to use Weblogic 8.1 style execute queues. That aside, there are configuration issues that need to be addressed for requeueing to ensure that the Weblogic instance does not run out of memory if messages cannot be processed for an extended period of time. By default there is no theoretical limit on the number of messages in a given queue, however unless configured properly, all messages in a given queue are kept on the JVM heap (even if persisted), until they are processed. This can lead to out of memory exceptions if a queue begins to back up. Thus we will need to configure memory to disk paging for all JMS servers that have queues where messages could be requeued multiple times. Paging is implemented by specifying a directory where the paging file will be written along with setting limits on the message buffer size. Once this limit has been reached, Weblogic will page the message bodies out to disk to prevent the instance from running out of memory.  Weblogic recommends setting the message buffer size to Max JVM heap size minus the heap size of the instance running under normal load. Thus if you had 512mb max heap, and the instance normally ran at about 400mb utilized then you would set the byte threshold to 112mb. Although that may bring the instance too close to the Max memory and so we recommend at least 32mb under that value as a buffer. Regardless, since paging can only be directed to disk, we will have to implement the new disk slice recommendations (see File Store section above) even if we go with JDBC based persistence.

 

 

 

The findings were surprising since the average processing time of a JDBC persisted message was actually smaller than having no persistence store at all.  However, multiple tests confirmed that JDBC persistence proved to be the most efficient.

 

 

Other configuration settings to consider
Regardless of whether JDBC or File Store is chosen as the persistence mechanism, we may wish to override some of the default settings on JMS servers and in most cases the Queues themselves.  These settings are as follows:

  • Delivery Mode Override (Queue Configuration): If all messages should be persisted then this setting should be set to Persistent. This ensures all messages are persisted, not just those messages that have the delivery mode set to persistent. This will be left up to individual teams to decide whether or not to override the delivery mode within the message.
  • Paging Directory: Should point to the JMS Persistent store disk slice. This is where messages will be written once the Message Buffer Size threshold has been reached.
  • Message Buffer Size: Should be set to max heap minus normal operating heap minus 32mb (per WIS recommendation). Once this limit is reached, messages will be paged to disk to prevent the instance from running out of memory.
  • Redelivery Delay Override:  This option can be set to tell Weblogic how long to wait before attempting to redeliver a requeued message. The default behavior is to wait 10 seconds the first time, 20 seconds the next time and so on.
  • Redelivery Limit:  Can be set to limit the number of times a message will be redelivered. If overridden and the limit is reached and no error destination is configured, the message will simply be discarded.
  • Expiration Policy: Will tell Weblogic what to do with expired messages. The options are Discard, Log or Redirect.
  • Expiration Destination: The destination that expired messages will be sent to if Expiration Policy is set to Redirect.

 

##############################################################################################

QuickBytes About JVM in Weblogic

whats the maximum heap size allowed in weblogic 8.1 or 9.1?

It’s not restricted by weblogic, it’s the restiction at JVM level. if the JVM is 32-bit , maximum heap size you can allocate is 4 GB(remember, in this 4 GB, you need to give some space to OS functions, so you may give 3.5 GB max memory to application and 0.5 GB to OS). if the JVM is 64-bit you have plentiful, i mean hundreds of GB for your heap.

 whats the default GC algorithm used in weblogic?

Again, this is dependant on JVM, if you are using Sun Java Hotspot Server JVM, default GC is Parallel GC. it’s a multi threaded GC collector which works only on young-generation space, i.e. it collects the memory used by invalid “new” objects, not the old objects. old objects will be in tenured/old generation space.

How do you make an application to start fast?

From JVM Perspective, if you use a Java Hostspot VM client , then your application will start fast, because it doesn’t do lot of optimisation while compiling the code( are you crazy, whats the compilation you are talking?aren’t we give .class files to the JVM, instead of .java, then whats the compilation i’m talking about? hold your breath. Sun named this JVM as hotspot, because even in .class files/byte code, some byte code methods takes lot of time in execution,those are called “hotspots” and the hotspots are analyzed even further and compiled. so we are compiling the byte code. got it?). Note: we can’t use client JVM for all applications- if your appliaction is light-weight one, let say , GUI based, where all the processing done at GUI, then you can use it.

Where does the objects created in heap ?
Objects first gets created in eden space(which is part of young generation=eden+survivor spaces) and if they ling longer and some other new objects coming into pipe- these old objects have to make room for them, so garbage collector thread moves them into tenured space or old gen space.

 

##############################################################################################

Fixing the Basic Authentication issue until versions Weblogic 9.0 to Weblogic 12.

We had  a requirement to ask credentials when a user is going to access certain page in an application. We configured the user in Iplanet webserver and created ACL. Then when we entered the http://www.website.com/context , it does prompt for the username and password once we enter it prompts again weblogic username and password.

For resolving this you need to add below line in the config.xml of weblogic server. If there is a request to the weblogic server which has basic (HTTP authentication )Authorization header , weblogic will be intercepted and will not allow you to the application until you provide the credentials of weblogic server.

Solution:
Add below line before </security-configuration> of your config.xml.
<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>

That resolve your issue.

Let me know if you have any questions.

 

 

 

Leave a comment