Recently during a test done on an EJB, I got the following exception.
It turned out that the reason for this exception is, the listen address (lets say "lstnr01") declared in the managed server in Weblogic Admin console is different from server name (although it is a correct address to that machine, I can use it to connect to weblogic console and do ssh) I used for initiating the connection to EJB. You can check the listen address of the server by browsing to "Environments"->Servers->YourServer->Configuration->General. In that page, there is a text box to enter "Listen Address".
Now after finding the reason for the problem, next problem I got is I cannot use this listen address "lstnr01" to connect to my machine, because that is not registered in a DNS server in the network. The mapping of "lstnr01" to that machine was only configured in the "/etc/hosts" file of the server.
Therefore to fix that issue, I added the same IP host name mapping entry to map "lstnr01" to server IP in the C:/Windows/system32/drivers/etc/hosts/hosts file.
Then I executed the "ipconfig /flushdns" command using the command line. It refreshed the DNS cache of the local machine and updated the cache with newly added entry in the hosts file.
Then I used "lstnr01" as the remote server address instead of "server01" when connecting to the EJB.
Then the above exception was gone and I was able to connect to the EJB and run the EJB method successfully.
javax.naming.
CommunicationException [Root exception is java.net.ConnectException: t3://server01:7101: Bootstrap to server01/10.10.58.26: 7101 failed. It is likely that the remote side declared peer gone on this JVM]
javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://server01:7101: Bootstrap to server01/10.10.58.26: 7101 failed. It is likely that the remote side declared peer gone on this JVM]
at weblogic.jndi.internal.ExceptionTranslator. toNamingException( ExceptionTranslator.java:40)
......
Caused by: java.net.ConnectException: t3://server01:7101: Bootstrap to server01/10.10.58.26:7101 failed. It is likely that the remote side declared peer gone on this JVM
at weblogic.rjvm.RJVMFinder.findOrCreateInternal( RJVMFinder.java:216)
..............
... 25 more
Caused by: java.rmi.ConnectException: Bootstrap to server01/10.10.58.26:7101 failed. It is likely that the remote side declared peer gone on this JVM
at weblogic.rjvm.ConnectionManager.bootstrap( ConnectionManager.java:334)
at weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal( RJVMManager.java:254)
at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java: 197)
at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer( RJVMFinder.java:238)
at weblogic.rjvm.RJVMFinder.findOrCreateInternal( RJVMFinder.java:200)
... 31 more
It turned out that the reason for this exception is, the listen address (lets say "lstnr01") declared in the managed server in Weblogic Admin console is different from server name (although it is a correct address to that machine, I can use it to connect to weblogic console and do ssh) I used for initiating the connection to EJB. You can check the listen address of the server by browsing to "Environments"->Servers->YourServer->Configuration->General. In that page, there is a text box to enter "Listen Address".
Now after finding the reason for the problem, next problem I got is I cannot use this listen address "lstnr01" to connect to my machine, because that is not registered in a DNS server in the network. The mapping of "lstnr01" to that machine was only configured in the "/etc/hosts" file of the server.
Therefore to fix that issue, I added the same IP host name mapping entry to map "lstnr01" to server IP in the C:/Windows/system32/drivers/etc/hosts/hosts file.
10.10.58.26 lstnr01
Then I executed the "ipconfig /flushdns" command using the command line. It refreshed the DNS cache of the local machine and updated the cache with newly added entry in the hosts file.
Then I used "lstnr01" as the remote server address instead of "server01" when connecting to the EJB.
Then the above exception was gone and I was able to connect to the EJB and run the EJB method successfully.
