on 09-25-2005 4:35 PM
Hi all,
I've developed a simple J2EE application. This application consists of a WebApp and an EJB. The EJB runs on a different server to the WebApp, so I'm using the standard Remote Invication code to connect. I can't paste the code here, and it's on a different machine. Suffice it to say, however, that from reading through the forum, it's no different from any other code that's there.
We have 4 environments here. 2 of then enviroment consists of 2 servers - one is running WebAS 6.40 with EP6, and the other is just running WebAS 6.40. These are Dev and SysTest. The other 2 environment are clustered, with 2 of each of the aforementioned boxes setup in a cluster.
This is all running on Window2003
My application is running on the WebAS + EP6 servers only.
When I run my application on Dev and get it to connect to a server on SysTest, it connects no problem, and everything works as expected.
When I run it on SysTest and get it to connect to one of the UTT servers, it fails.
When I take the code for getting the InitialContext and doing the lookup() and run this in a standalone Java class from the command line, it will connect from the SysTest server to the UTT server with no problems.
I can't see why it should fail when running within the WebAS server, and not fail when running on the same box from the command prompt.
I have tried to connect by giving it and Adminstrator user details, and by not giving it those details. On the cluster, I have tried to connect to the DI and CI instances seperate, and to the virual IP of the cluster. All to no avail.
The errors that I have been receiving are:
- BaseLoginException: Cannot create new RemoteLoginContext instance.
- P4BaseConnectionException: Incorrect client ID. The stub is not connected yet.
among others.
(both of the above are the root cause of a NamingException)
Has anyone any ideas on what I can do to resolve this. I know my application works (as proved from connection from Dev to SysTest), and I know it's not a firewall issue (as proved by running the InitialContext code from the command line).
Thanks,
Gary
Gary,
I don't really have a solution since I don't have any experiences with a clustered WAS.
But from the exceptions I would rather guess that the problem might be caused by the connection information itself.
Did you check whether the string value for your variable server can be resolved from the calling workstation (ping in a DOS-Box) ?
Do you call the correct server ? I would guess you will have to address the dispatcher, not an individual server ip.
Are you using the correct ports ? The ports for the p4 access depends on the server instance number.
That's just a view ideas from my side. I hope you will find a solution.
And yes, firewall would have been my first idea, too.
Regards, Astrid
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your reply Astrid.
Using a standard Java class from the DOS prompt, I am able to make a connection on the IP address and Port that I am trying to use in the J2EE connection. I don't receive any errors on the DOS version.
So this would tell me that
1) it is the correct port
2) it is the correct IP address
I have adjusted my DOS based class to connect to the virtual IP of the cluster and it has failed to connect with a "No server running" error, which isn't surprising.
On the cluster, I have tried to connect to both servers from the J2EE application with no joy. My DOS class will connect to either server with no problems.
If I provide a username and password, the DOS class will still connect to both servers. The J2EE application won't.
Thanks for your suggestions, though. When (if?) I find a solution, I will post it here.
Gary
That's looking promising, Gonzalo. Indeed, the brokerID on one of the clusters was the default (I haven't checked the other cluster, but I have to assume it was also the default - the same people setup both clusters).
I am in the progress of restarting one of the clusters to see if my problem will go away. I am hopeful (assuming, that is, that the cluster start up !! )
I'll let you know how it goes shortly.
Gary
I rechecked our SysTest to UTT link again - When I tested, SysTest was pointing to the servers whose brokerid I hadn't changed at the time.
I have since changed the brokerid on all UTT and Prod servers, and now the link from SysTest to UTT is working fine.
Seemingly this problem only occurs when doing remote EJB lookups to a cluster from another WebAS box - it doesn't seem to matter if the source WebAS box is in a cluster or not, just the destination WebAS box.
Gary
After another discussion with our firewall guy, it turns out that UTT and Prod clusters are on the same subnet - there is no firewall between them
We are still unable to communicate between them.
When I don't have a username and password in the code, I get a NamingException. root cause: P4BaseConnectionException: Incorrect client ID. The stub is not connected yet
When I do use a username and password (using the Administrator user), I get
root cause: BaseLoginException: Cannot create new RemoteLoginContext instance
Anyone?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I had sent this in an email to someone asking for help. I t contains more detail than I had in my original post.
--
We have the follow setup for our environments:
Dev and SystemTest have 2 servers - one is running a WebAS 6.40 instance
and has Oracle installed. The other is a WebAS 6.40 instance with EP
6.0 installed. Any EP application are installed on the EP box
(naturally), and other applications are installed on the WebAS only
boxes.
We have 2 clustered environments - User Test (UTT) and Production
(Prod). Both of these have 2xWebAS boxes in a CI/DI cluster
arrangement, 2xWebAS+EP6 boxes in a CI/DI cluster arrangement, and
2xOracle boxes in a cluster.
All of our servers are running Windows 2003, and the clustering is
Windows clustering. Each cluster has it's own Virtual IP. Standard
stuff, really.
We have written small utility to allow users to publish KM content
easily from the UTT environment into Prod - we don't give our users
direct access to the KM on our production systems . This utility works
very well between Dev and SystemTest, where we did all of our testing.
However, we are having an issue running this between SystemTest and UTT,
and between UTT and Prod.
The error we get occur when we try to get the InitialContext.
Here is the code:
private void createHandle() throws CPUException {
String server;
String port;
try {
server = CPUDao.getInstance().getServer();
port = String.valueOf(CPUDao.getInstance().getPort());
} catch (CPUException e) {
Logger.log(e.getMessage(), e);
throw e;
}
try {
String url = server + ":" + port;
Logger.log("URL is " + url);
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sap.engine.services.jndi.InitialContextFactoryImpl");
properties.put(Context.PROVIDER_URL, url);
//properties.put(Context.SECURITY_PRINCIPAL, "Administrator");
//properties.put(Context.SECURITY_CREDENTIALS, "password_here");
properties.put("force_remote", "true");
intialcontext = new InitialContext(properties);
object = intialcontext.lookup(CPUConstants.EJB_URL);
if (object==null) {
throw new CPUException ("lookup returned null");
}
CPUKmSessionHome cpuKmSessionHome =
(CPUKmSessionHome)PortableRemoteObject.narrow(object,
CPUKmSessionHome.class);
if (cpuKmSessionHome!=null) {
cpuKmSession = cpuKmSessionHome.create();
} else {
throw new CPUException ("Received a null Home object!!");
}
} catch (NamingException e) {
Logger.log("Naming Exception: " + e.getMessage(), e);
Logger.log("Exception is : " + e.getClass().getName());
Logger.log("Cause is: " + e.getCause());
Logger.log("Explaination is: " + e.getExplanation());
Logger.log("RemainingName is: " + e.getRemainingName());
Logger.log("ResolvedName is: " + e.getResolvedName());
Logger.log("toString() return: " + e.toString());
throw new CPUException(e.getMessage(), e);
} catch (RemoteException e) {
Logger.log("Remote Exception: " + e.getMessage(), e);
throw new CPUException(e.getMessage(), e);
} catch (CreateException e) {
Logger.log("Create Exception: " + e.getMessage(), e);
throw new CPUException(e.getMessage(), e);
} catch (Exception e) {
Logger.log("Other Exception: " + e.getClass().getName() + ": " +
e.getMessage());
StringWriter sw=new StringWriter();
e.printStackTrace(new PrintWriter(sw));
Logger.log("Trace:<BR><pre><code>"+sw.toString()+"</code></pre>");
throw new CPUException(e.getMessage(), e);
}
}
I've a tonne of debug statements in there so that I can see what is
happening (Logger.log() logs to a static StringBuffer variable in,
appending a <BR>\n to each line - I can view this then using a webpage.
When an exception is passed in, it will print some of the stacktrace to
the log too)
It failed on the
intialcontext = new InitialContext(properties);
line.
At the moment it's coming back with a
priority: DEBUG - message: Naming Exception: Exception during
getInitialContext operation. No server is running.
Exception during getInitialContext operation. No server is running.
Or
priority: DEBUG - message: Exception is :
com.sap.engine.services.jndi.persistent.exceptions.NamingException
priority: DEBUG - message: Cause is:
com.sap.engine.services.rmi_p4.exception.P4BaseConnectionException:
Incorrect client ID. The stub is not connected yet.
priority: DEBUG - message: Explaination is: Exception while trying to
get InitialContext.
Strangely, if I take the above code and put it into it's own Class, and
run this from a command line, it will connect...
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import java.rmi.RemoteException;
public class JNDITest {
static String user=null;
static String pass=null;
public void createHandle() {
String server=" server_ip";
String port="50004";
try {
String url = server + ":" + port;
System.err.println("URL is " + url);
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sap.engine.services.jndi.InitialContextFactoryImpl");
properties.put(Context.PROVIDER_URL, url);
if (user!=null) {
properties.put(Context.SECURITY_PRINCIPAL, user);
properties.put(Context.SECURITY_CREDENTIALS, pass);
}
properties.put("force_remote", "true");
System.out.println("Properties are: " + properties);
System.out.println("Getting context...");
Context intialcontext = new InitialContext(properties);
System.out.println("Have context: " + intialcontext);
System.out.println("Looking up object:
diageo.com/CPUSystemApp/CPUKmSessionBean");
Object object =
intialcontext.lookup("diageo.com/CPUSystemApp/CPUKmSessionBean");
System.out.println("Have object: " + object);
} catch (NamingException e) {
System.err.println("Naming Exception: " + e.getMessage());
e.printStackTrace();
System.err.println("Exception is : " + e.getClass().getName());
System.err.println("Cause is: " + e.getCause());
System.err.println("Explaination is: " + e.getExplanation());
System.err.println("RemainingName is: " + e.getRemainingName());
System.err.println("ResolvedName is: " + e.getResolvedName());
System.err.println("toString() return: " + e.toString());
} catch (Exception e) {
System.err.println("other Exception: " + e.getMessage());
System.err.println("Exception is" + e.getClass().getName());
e.printStackTrace();
}
}
public static void main(String[] args) {
JNDITest j=new JNDITest();
if (args.length>0) {
user=args[0];
pass="";
}
if (args.length>1) {
pass=args[1];
}
j.createHandle();
}
}
The output from the above is:
URL is server_ip:50004
Properties are: {java.naming.provider.url= server_ip:50004,
java.naming.factory.initial=com.sap.engine.services.jndi.InitialContextF
actoryImpl, force_remote=true}
Getting context...
Have context: javax.naming.InitialContext@c2ff5
Looking up object: diageo.com/CPUSystemApp/CPUKmSessionBean
Have object: 248
where server_ip is the IP address of the CI instance on the WebAS+EP
box on UTT. Because this is occuring between ST/UTT and UTT/Prod, it
would appear that it could be a firewall issue. However, the
stand-alone class above connects which would negate the firewall issue.
Also, I had a firewall guy look at the issue, and he is not seeing
anything that is being blocked.
The connect from ST to UTT is to the CI instance directly. Same with
the connection from UTT to Prod. I have also tried connecting to the
Virtual IP of the cluster on UTT from ST to see if that would help - it
dodn't .
I haven't been able to find anything on the forums about this. Is it a
problem connecting remotely to an EJB in a cluster? Or another issue?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gary,
I guess you are getting error in lookup of EJb in your code.
What have you specified as JNDI name of your EJB and in your web application?
Check that again.
Regards,
Bhavik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The JNDI name is correct - this has also been proven by the app running correctly between Dev and SysTest. The same EAR file is deployed to all 4 environments (the IP address and port number to connect to are read from a database table)
The EJB reference is also in my web.xml and web-j2ee-engine.xml files (the jndi-name setting in the web-j2ee-engine.xml file is correct also - there is no jndi-reference in the web.xml file)
I have noticed that the ejb-name in my EJB xml files is not exactly the same as the ejb-ref-name in my web xml files (the web xml files have an ejb/ at the start)
Interestingly, when I changed the name in the web.xml file, the whole section was automatically removed from the web-j2ee-engine.xml file...
I'll try it like this and see what happens (not hopeful, mind).
Gary
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.