How to set timeout while testing a datasource using WLST.
When I do the testPool on a dataSource it waits indefinitely.
this also hangs the managed server.
is there a way we can set timeout?
Please set the below settings in the weblogic connection pools according to your requirement in weblogic console.
•Test Frequency—(TestFrequencySeconds in the JDBCConnectionPoolParamsBean) Use this attribute to specify the number of seconds between tests of unused connections. WebLogic Server tests unused connections, and closes and replaces any faulty connections. You must also set the Test Table Name.
•Test Reserved Connections—(TestConnectionsOnReserve in the JDBCConnectionPoolParamsBean) Enable this option to test each connection before giving to a client. This may add a slight delay to the request, but it guarantees that the connection is healthy. You must also set a Test Table Name
Related
I have a requirement where I have configured 'min-connctions= number of client thread * number of geode cache server'.
so that during load there will be not connection while accessing the connection or no new connection is needed if all threads start accessing to a single Server.
the problem is that it is locator who decide the how many connection client can create to a server JVM based on load probe.
I want to ignore everything just wanting equal number on Connections to all Cache Server JVMs.
We have multiple data sources in our weblogic(10.3.5) connecting to different DB servers (we have quite a few DB servers).
If any one of the DB server is down or the DB password changed/expired, the complete managed server is going to admin state.
I think this is because weblogic is trying to test the datasource while its coming up and since its unable to initialize the datasource, the server is not starting and going into admin mode.
Is there a way we can disable this feature? Our application has a logic to check the datasource if it is active (test connection) before the user starts using that datasource.
I am aware of weblogic JMX MBeans which can be used to disable/suspend. But to do this, we need to write a startup class. Not sure if this works, but If there's a configuration that we can set, we would prefer that.
On the Connection Pool tab for the datasource, set the Initial Capacity to 0. This will stop the initial check and the server should start properly.
Say, I am having N servers in the predis connection pool. I found that when one of the server does down, predis does not work(i.e. new predis/client(s1,s2,...) does not return successfully if any of the server Si is down). First, the entry of that failed server needs to be removed manually, and only after this predis resumes its work.
Since, predis claims to be using consistent hashing, shouldn't this be the case that predis automatically detects which of the server is not responding ( & has failed), and distribute the keys stored on the failed server to the other working servers?
Predis does use consistent hashing, but it is left to you to ensure that all servers in the pool are up and responding. Monitoring server availability is not intrinsically implied with consistent hashing.
You can check each server before you attempt to connect, and modify your connection pool based on your checks. You can store the available server list for the pool elsewhere and have some other process constantly watching and modifying the available server list. You could just assume they are always all up, and only check which ones need to be removed on a failure, or you can use any combination of the above. The bottom line is that predis does not, at the moment, do it for you.
Hi I have a application that is deploy on two weblogic app servers
recently we have issue that for certain cases the user session returned is null. Developer feedback is that it could be caused by the session not replicating to the other server.
How do we prove if this is really the case?
Are you using a single session store that both application servers can access via some communication protocol? If not, then it is definitely the case. Think about it, if your weblogic servers are storing the session in memory anywhere, and having users pass their session id via cookies, than the other server has no way of accessing the memory on the other machine. Unless you are using sticky load balancing. Are you?
There's 2 concepts to consider here - Session stickiness and session replication.
Session Stickiness is a mechanism where weblogic server ensures that if a request from a user with session A goes to server 1 then the next request from user with session A will go to server 1 only.
This is achieved by configuring a hardware loadbalancer (like F5) which is capable of providing session stickiness. or configuring weblogic proxy installed on apache/iis/weblogic.
The first time a request reached WLS managed server, it responds with a session id and appends to it the JVM id of the server (this is the primary id), if the managed server is part of a cluster, it also attaches a secondary server jvm id (the secondary server is the server where the session is being replicated)
The proxy maintains a table of all JVM id's and corresponding IP of managed server, it also checks periodically if the servers are up and running or not.
The next time when another request passes the proxy with existing session id and a primary jvm id, the proxy parses this and tries to send the request to that server, if it cannot within some time it tries to send to secondary server.
Session Replication - This is enabled by default when you configure a WLS cluster with 2 or more managed server. Each time any data is updates to a session, its data is replication in a secondary server too.
So in your case if your application users are loosing session or getting redirected to login page between normal usage, then check that the session did not get invalidated because of a timeout, if you have defined a cluster and using WLS proxy then check the proxy debug output to make sure the primary and secondary server are being appended to the session id.
Finally there's a simple example in the sample application deployment of wls that you can use to test session replication and failover functionality.
So to prove why session is getting lost,
1) check server log to see if session got invalidated because of timeout,
2) if using wlproxy, enable debug, and the next time the issue happens check in the proxy log if the request was sent to a different server, and if that server is not the secondary server.
Whenever I change connection pool parameters (url, id, pwd etc) I try to deploy the new connection pool in weblogic using the Control tab. I do a shutdown and start which IMO should redepoly the new connection pool.
But the changes take effect only when I restart the server. What other parameters need to be tuned to avoid restarting the server?
Thank you!
You need to untarget and retarget that specific connection pool to the server or cluster, that should be enough.
You dont have to restart the whole WL server.
Some settings require reset (or redeploy) and some don't.
To find out which option requires restart/redeploy you should click on [More info ...] near option description (or go to
JDBC Data Source -> Configuration -> Connection Pool)
In example, you will find out that Maximum Capacity does not require restart.
But for Pinned-To-Thread option it says:
Changes take effect after you redeploy the module or restart the server.