Oracle SOA 11g - Disabling the Auto recovery of Faulted Instances,invoke and callback messages

Hi Friends,

　

Greetings to Everyone... !!!

Hope you all doing well. today we will talk about some SOA issue faced by one of my friend. We analyze this issue and found below solution.

Problem Statement :

We observe that there is excessive growth in DB from SOA applications. It generally happened when there are some failures in application calls.

Solution found is disabling the Auto recovery of Faulted Instances ,invoke and callback messages.

Let's talk about auto recovery, auto recovery is the functionality to recover the faulted instances and Invoke and Callback messages in SOA 11g.

Sometimes we need to disable this feature to avoid unnecessary table space growth and recovering the instance that fail even after the recovery.

Disabling recovery attempts for faulted instances.

Step 1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

Step 2. Right-click soa-infra.

Step 3. Select SOA Administration > BPEL Properties.

Step 4. Click More BPEL Configuration Properties.

Step 5. In the Name column, click RecoveryConfig.

Step 6. Expand RecurringScheduleConfig.

Step 7. Set the following properties to values and click Apply.

maxMessageRaiseSize =0

Step 8. Expand StartupScheduleConfig, respectively.

Step 9. Set the following properties to values and click Apply.

maxMessageRaiseSize=0

I hope this will help in your issues.

Keep working on Middleware technologies and write me if you need any further help.

In case of any queries or question, you can write me on middlewaresolution1@gmail.com.

Regards,
Ajinkya Vicharehttp://ajinkya-vichare.blogspot.com

 

weblogic.socket.MaxMessageSizeExceededException in OSB11g

Hi Friends,

Greetings for the day..!!!

First of all Happy New year to you and your family..!!! Hope this year will be best technology year of your life.

I'm Writing this blog after so many days/month. I have got one query/question on email. Let's discuss on that problem today.

please find below problem statement for OSB and solution along with it.

Whenever we have a long running two-way OSB-DB API call.it takes much time to complete. It will show us the weblogic.socket.MaxMessageSizeExceededException in sbconsole debug console.

We can find below stack trace for the same :

  

Cause: weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'

After checking logs and stack trace, have found below solution or rather workaround for this issue.

Solution:

Step 1. Go to servers--->protocols--->general--->max message size--->change the value to sufficient memory (Do this for both the admin and the osb/soa). Please do it for all the OSB/SOA nodes in the cluster

Step 2. Go to servers--->configuration--->server start--->arguments--->-Dweblogic.MaxMessageSize = 20000000

Step 3. Restart all the servers.

Hope this will help you to resolve this issue.

Note: Please take back for configuration before doing any change on OSB.

In case of any queries or question, you can write me on middlewaresolution1@gmail.com.


Regards,
Ajinkya Vichare
http://ajinkya-vichare.blogspot.com

How Threads work in Oracle Weblogic Server ??

Hi Everyone,

Greetings all of you.. !!!

Hope you all are doing well. Last week I had technical discussion with few consultants from leading companies in our industry. I have found that many of them were not aware of working of threads, connection pool and Node manager. So thought of writing on those topics. So today will talk about working of thread or I would say lifecycle of thread in weblogic.

I have tried to simplify some of points in this blogs, also have taken some help from few weblogic experts blogs. So hope it will help you in clearing all your queries on thread life cycle.

Step 1. Whenever there is request on weblogic as entry point, client contacts the ListenThread which accepts the connection. It then registers the socket with a WLS component known as the SocketMuxer for further processing.

Step 2. The SocketMuxer is responsible for reading and dispatching all client requests to the proper WLS container. It then adds this socket to an internal data structure for processing and makes a request of an ExecuteThreadManager to create a new SocketReaderRequest. This request is then dispatched by the manager to an ExecuteThread

Step 3. As a result, the ExecuteThread becomes a SocketReader thread - it will continually run the SocketMuxer’s processSockets and checks the muxer’s queue to determine if there is work to be done. If an entry exists, it pulls it off the queue and processes it.

Step 4. The SocketReader thread reads the client request and determines the protocol type of this client request, to create a new protocol specific MuxableSocket.

Step 5. The MuxableSocketDiscrminator stores a new MuxableSocket with the implementation matching the protocol of the client. It also returns true to the SocketReader to notify it that the message is complete and it can be dispatched.

Step 6. MuxableSocketDiscriminator re-registers the protocol specific version of the MuxableSocket that was created earlier. The net result is that “Step 2” is repeated, and a new protocol specific MuxableSocket is placed in the SocketMuxer’s queue for processing.

Step 7. A socket reader will get the new protocol specific MuxableSocket off the queue and read it. It will then checks to see if the message is complete, based on the protocol. If it is, it will invoke the protocol specific MuxableSocketDiscriminator

Step 8. Before the work requested by the client can be performed, there may be many iterations of “Step 7”. This is determined by the protocol – for example, t3 will read a portion of the message, dispatch it so it can act upon the portion of the protocol read thus far.

Step 9. The subsystem will create an ExecuteRequest and send it to an ExecuteThreadManager for processing. The request is dispatched to an ExecuteThread, and the result is returned to the client.

These are all basic steps or life cycle for Oracle Weblogic Server Threads.

From a high level overview’s from socket muxer perspective, Each and every socket connection that comes into WebLogic Server is “registered” with the SocketMuxer - which then maintains a list of these connections, each represented by a form of the MuxableSocket interface. It then becomes the responsibility of the SocketMuxer to read and dispatch each client request to the appropriate subsystem. This is a fairly elaborate process, which is illustrated by steps 2 through 8 above.

There are only a few key things to know about the SocketMuxer:

First, it has a data structure in which it stores a socket entry for each client connected to WebLogic Server.
Second, a “socket reader” is the main component of the SocketMuxer - which really is just an execute thread that is running the SocketMuxer’s processSockets() method.

Third, the SocketMuxer does most of its work through the only interface it knows how to operate on – the MuxableSocket interface.

Socket Reader:

A SocketReaderRequest is merely an implementation of an ExecuteRequest, which is sent to the ExecuteThreadManger by the invocation of the registerSocket(). When the ExecuteThread invokes the execute() method of the SocketReaderRequest, the SocketMuxer’s processSockets() method is invoked.
So, a socket reader thread is simply a normal execute thread which runs the main processing method of the SocketMuxer, processSockets().


The acceptBacklog parameter of Weblogic server is passed to ServerSocket. The value of acceptBacklog means "The maximum queue length for incoming connection indications (a request to connect) is set to the backlog parameter. If a connection indication arrives when the queue is full, the connection is refused. "

Thus if too many connects come on the server at the same time, the server would queue this connects and process them one at a time. The value does not mean that only that many clients can connect to the server.

It does not limit the number of connections made. It limits the number of potential connections that can lie in the backlog queue. So for e.g.: AcceptBacklog is 2. If hundreds of connections were made to the server and the server has one thread to accept new connections.

This thread accepts the new connection and dispatches it to a new thread and then goes back to listening to new connections. Sample code is

while (true) {

Socket sock = serversocket.accept();
new MyThread(sock).run();

}

Here the thread accepts a new connection at line1. Dispatches to new thread in line 2. Evaluates the while expression and goes back to line 1. So in between the time it takes for it to get back to line 1(say T1) many new connections requests are made by the clients. These new connections lie on the accept backlog queue and this queue length is controlled by the accept backlog parameter.

If the queue length is 2, and between this time T1 several hundred connections are made to the server only 2 would get accepted and rest of them rejected. For rejection there must be too many simultaneous requests to the server, if it’s not simultaneous then the chances of queue getting full is less.

I hope it will help you in understanding about Thread Lifecycle of weblogic. I would like to thanks many Oracle Weblogic Experts who have written blogs on such topics.

Please write if you have any queries or you need to do some technical discussion. Your suggestions are always welcome. I May reply you late due to my hectic schedule but will surely answer on your email.

Thanks & Regards,

Ajinkya Vichare

Ajinkya-vichare.blogspot.com

Reset the AdminServer Password in WebLogic 11g and 12c

Hello Everyone,

After a long time posting something which is  very easy to implement and important as part of administrators work.

If you forget the AdminServer password for your WebLogic 11g domain, you may have multiple options to recover the same. here we are going to discuss about resetting it from the command line using the following process.

We will check this process step by step :

Step 1:

Set up the following environment variables. They are not necessary for the process itself, but will help you navigate.In this case my domain is called "12C_Domain". Remember to change the value to match your domain.

export MW_HOME=/Oracle/Middleware

export DOMAIN_HOME=$MW_HOME/user_projects/domains/12C_Domain

Step 2:

Shutdown all domains including managed server, Admin server and Node Manager.

./stopWeblogic.sh or kill -9 <process_id>

Step 3:

Rename data folder from below path i.e. in my case $DOMAIN_HOME/servers/AdminServer

mv $DOMAIN_HOME/servers/AdminServer/data $DOMAIN_HOME/servers/AdminServer/data_bkp

Step 4 :

set environment variable for domain as follows

./setDomainEnv.sh

Step 5:

Reset the password using the following command. Remember to substitute the appropriate username and password.

change directory to security folder :

cd $DOMAIN_HOME/security

run below command to change admin password :

java weblogic.security.utils.AdminAccount weblogic admin123 .

Note : weblogic is user name and admin123 is new password which we need to set.

Step 6:

If you specify password in boot.properties then you have to change it in below files :

Update the "$DOMAIN_HOME/servers/AdminServer/security/boot.properties" file with the new username and password. The file format is shown below.

username=weblogic

password=admin123

Step 7:

Now start admin server as follows with new credantials .

./startWeblogic.sh

I know this is very easy steps but many of the time we unable to recollect easy steps to handle such issues or operations.

If you have any queries you can write me on middlewaresolution1@gmail.com

Regards,

Ajinkya Vichare

ajinkya-vichare.blogspot.com

BEA-000362 Server failed. Reason: Parsing Failure in config.xml: java.lang.IllegalArgumentException

Dear All,

Greetings...!!!!

This post i am writing after so long.. I hope you all are doing well.. 

Today we will be talking about Weblogic Error While starting weblogic Server. one of my friend stuck with below error while starting weblogic after monthly log purging. He had received below error in logs

"BEA-000362 Server failed. Reason: Parsing Failure in config.xml: java.lang.IllegalArgumentException "

 

 After checking weblogic server we have found below solutions for the same.

Solution: -

This happens when MW_HOME is not defined and weblogic.jar is getting called twice in CLASSPATH. To fix this, check below two points :

• Ensure weblogic.jar in CLASSPATH is not duplicated. You can check CLASSPATH section when it prints while starting.
• Set MW_HOME either on unix shell or in startup scripts.

MW_HOME=/Weblogic/wls1036/

Start WebLogic now, it should work!

 Enjoy working with Middleware Technologies. If you have any queries kindly write me on middlewaresolution1@gmail.com

Regards,

Ajinkya Vichare