Deploy app with weblogic.deployer task
set the environment path
java weblogic.Deployer -deploy -adminurl t3://<DNS_NAME>:<PORT> -username <USERNAME> -password <PASSWORD> -name <APP_NAME> -targets <SERVER_NAME>,<CLUSTER_NAME> <APP_PATH>
java weblogic.Admin -url t3://<DNS_NAME>:<PORT> <USERNAME> -password <PASSWORD> FORCESHUTDOWN <SERVER_NAME>
How to rename weblogic domain name
Changing weblogic domain name is possible with modifying certain files under your domain.
In this exercise – I have renamed from wl-dstba to wl-amgenpact
1) Take complete backup of your domain
2) Copy old domain name folder to new domain name
cp -rp wl-dstba wl-amgenpact
cp -rp wl-dstba wl-amgenpact
3) Search all files which contains dstba in newly copied folder
[wlapp@alvdstlwls004aq server1034]$ pwd
/pae/alvdstlwls004aq-3/weblogic/dst/server1034/wl-amgenpact
/pae/alvdstlwls004aq-3/weblogic/dst/server1034/wl-amgenpact
grep -rl dstba *
4) Replace dstba with amgenpact name
grep -rl dstba . | xargs sed -i -e 's/dstba/amgenpact/'
Ensure none of the files are having base_domain
[wlapp@alvdstlwls004aq server1034] grep -r dstba *
5) Restart the JVM's to verify servers are coming up.
MULTICAST TEST
NIC is fun
ctioning properly. To check whether network communication is proper or not, you may use the following Java utility:$ java utils.MulticastTest -n name -a address [-p portnumber] [-t timeout] [-s send]
Where name is the name of the server and address is the multicast address. To get more details regarding this utility you can refer the below link also.
http://e-docs.bea.Also, in the past, I saw a similar issue which was caused by the interface and mulitcast, it was resolved by removing the multicast bind to the user interface in the static routing table.
Give it a try and let us know if this fixes the issue.
JDBC Connection Reset when using many processes on 64 bit system
java.security.SecureRandom is a standard API provided by sun. Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during login. Users using Linux have been encountering SQLException("Io exception: Connection reset").
The problem is two fold
1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the method takes a long time to respond and hence cause the server to timeout
2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException("Io exception: Connection reset") Users upgrading to 11g can encounter this issue if the underlying OS is Linux which is running on a faulty hardware.
Cause-------
The cause of this has not yet been determined exactly. It could either be a problem in
your hardware or the fact that for some reason the software cannot read from dev/random
your hardware or the fact that for some reason the software cannot read from dev/random
Solution ---------
Change the setup for your application, so you add the next parameter to the java command:
Change the setup for your application, so you add the next parameter to the java command:
-Djava.security.egd=file:/dev/../dev/urandom
No comments:
Post a Comment