Hi,
First, i'm not an expert in notification matters, adding core folks on cc, hope
they don't filter that message away because ws-gram is in the subject.
We are using WSGRAM v4.0.6 to submit jobs to a PBS cluster from the an
external application. For each job submitted to WSGRAM we request that
job state notifica
tions are sent directly back to our external
application.
This has worked well when the notifications are sent back to the
application unencrypted. However, we attempt to encypt this traffic
using SSL(ie send the notifications to https://domain.com), no
notificaitions are recieved at the external application.
How did you do that?
Do you setup the NotificationConsumerManager using GSIServiceContainer?
If you use just ServiceContainer this won't work.
(
Map properties = new HashMap();
properties.put(ServiceContainer.CLASS,
"org.globus.wsrf.container.GSIServiceContainer");
this.ncm = NotificationConsumerManager.getInstance(properties);
this.ncm.startListening();
)
Do you have GSITransport (assuming you are using 4.0.x) as authentication method
in the resource security descriptor when you create the NotificationConsumer at
the NotificationConsumerManager?
Rachana, Tom, correct me if the below is wrong:
I have checked the following
* There is no log entry indicating a error or warning that there
has been a problem(debug is turned on)
* A PersistentSubscription object file is created for the job in
the Persisted directory
* I have sniffed the network traffic and I do see 2 tcp
connections between the WSGRAM server and the external application.
My assumption is that the sending of the job state notification is
failing because of an SSL related warning (ie SSL cert error such as
"Do not trust the CA " or "host name mis-match"). Thus my questions
are
1. Is my assumption above correct
2. If so, is there a way I can turn off the behavior where the
connection will fail on a warning?
Try adding
log4j.category.org.globus.wsrf.handlers.MessageLoggingHandler=DEBUG
to $GLOBUS_LOCATION/log4j.properties (not container-log4j.properties!)
You then should see something like the following in error situations
on the client-side:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server.generalException</faultcode><faultstring>GSI Secure
Message authentication required for "{http://wsrf.globus.org/core/notification}notify" operation.</faultstring><detail><ns1:stackTrace
xmlns:ns1="http://xml.apache.org/axis/";>GSI Secure Message authentication required for "{http://wsrf.globus.org/core/notification}notify" operation.
at
org.globus.wsrf.impl.security.authentication.AuthHandler.handle(AuthHandler.java:121)
at
org.globus.wsrf.impl.security.authentication.SecurityPolicyHandler.handle(SecurityPolicyHandler.java:112)
at
org.globus.wsrf.impl.security.authentication.DescriptorHandler.invoke(DescriptorHandler.java:91)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:248)
at
org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:664)
at
org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:382)
at
org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:153)
at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:291)
As far as i know nothing is printed on the server-side, the notifications
fail silently.
3. Also, for the job state notification connection, where is the
TRUSTED_CA directory, is it in the standard location of either
~.globus/certificates or /etc/grid-security/certificates?
Yes, i think so.
Martin
Thank you in advance for the assistance with this,
Brian Connolly
