Dear Eduardo,
thanks for your answer. However, I now ensured that the variable is set,
according to some page which I found I also set tcp.port.range in
~/.globus/cog.properties, I even disabled the firewall(s), yet to no
avail: the same warning message appears. Do you have any more ideas on
what to try? Can the VM be a problem? What could I try to test this?
I signed up for egcf, but for the ticketing system I need an account
which I don't have (yet) and don't know where to get it from.
Thanks,
Timo
Am 07.07.2011 12:14, schrieb Eduardo Huedo:
Dear Timo,
Since it says "Connection refused", first of all, ensure that you don't
have any firewall problem.
For example, check that GLOBUS_TCP_PORT_RANGE is appropriately set in
the client. As you probably know, the client starts a small container to
receive notifications in a user-space dynamic port. This variable limits
the range of these dynamic ports, so only that range should be open in
the firewall.
For your information, the IGE project (http://www.ige-project.eu) is now
providing support (and much more) for Globus in Europe. For example, we
have a request tracking system (http://rt.ige-project.eu) where you can
open a ticket to request support, suggest improvement or report bugs.
Regards,
Dr. Eduardo Huedo Cuesta
Associate Professor (Profesor Titular), Universidad Complutense de Madrid
http://dsa-research.org/ehuedo
2011/7/7 Timo Henne <[email protected]
<mailto:[email protected]>>
Hi,
my previous two mails somehow didn't make it to the list, so here is
another attempt:
I am trying to use gridway(5.6.1) to schedule simple test jobs (/bin/ls)
across two machines, both with gt4.2.1 installed and running. One of the
machines is running Debian, the other is a VM running Ubuntu.
Communication and Authentification apparently works fine, the machines
see and trust each other, and the jobs gets scheduled. However, in *both
directions*, only those jobs running on the local machine (from where
they are started using gwsubmit) actually get "done" - the others remain
in "wrap pend" state. Apparently they are executed correctly on the
remote machine, since the result output is there, but somehow the
notification to the originating machine fails. Searching the list,
enabling debugging and digging in the logs I found this
warning/exception at the
end of the globus container.log on the remote machine:
<...snip...>
2011-07-01T15:40:41.231+02:00 INFO impl.DefaultIndexService
[ServiceThread-58,__performDefaultRegistrations:__261]
guid=b646c8e0-a3e7-11e0-b059-__b76342becd29
event=org.globus.mds.index.__performDefaultRegistrations.__end status=0
2011-07-01T15:41:21.751+02:00 INFO
PersistentManagedExecutableJob__Resource.ce605ef0-a3e7-11e0-__b059-b76342becd29
[ServiceThread-57,start:761] Job ce605ef0-a3e7-11e0-b059-__b76342becd29
with client submission-id null accepted for local user 'the'
2011-07-01T15:41:22.032+02:00 INFO handler.SubmitStateHandler
[pool-1-thread-7,process:172] Job ce605ef0-a3e7-11e0-b059-__b76342becd29
submitted with local job ID
'ce9b08e8-a3e7-11e0-bcc8-__b7ebd4913b23:17697'
2011-07-01T15:41:23.327+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-1,setPort:287] Security properties not null: not
secure conv
2011-07-01T15:41:23.327+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-1,setPort:314] set port with false
2011-07-01T15:41:23.366+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-1,setPort:290] Setting security properties
2011-07-01T15:41:23.482+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-3,setPort:287] Security properties not null: not
secure conv
2011-07-01T15:41:23.483+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-3,setPort:314] set port with false
2011-07-01T15:41:23.483+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-3,setPort:290] Setting security properties
2011-07-01T15:41:23.505+02:00 WARN
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-3,topicChanged:__129] [JWSCORE-169] Failed to send
notification for subscription with key
'__B26B14DD21498C52B1E38CC2F042B0__AF0E65BAE6+ce647da0-a3e7-11e0-__b059-b76342becd29':
java.net.ConnectException: Connection refused
2011-07-01T15:41:23.506+02:00 DEBUG
impl.__SimpleSubscriptionTopicListene__r
[pool-1-thread-3,topicChanged:__132]
javax.xml.rpc.JAXRPCException: java.net.ConnectException: Connection
refused
at org.apache.axis.client.Call.__invokeOneWay(Call.java:1871)
at
org.oasis.wsn.__NotificationConsumerSOAPBindin__gStub.notify(__NotificationConsumerSOAPBindin__gStub.java:701)
at
org.globus.wsrf.impl.__SimpleSubscriptionTopicListene__r.notify(__SimpleSubscriptionTopicListene__r.java:256)
at
org.globus.wsrf.impl.__SimpleSubscriptionTopicListene__r.topicChanged(__SimpleSubscriptionTopicListene__r.java:123)
at
org.globus.wsrf.impl.__SimpleTopic.topicChanged(__SimpleTopic.java:205)
at
org.globus.wsrf.impl.__SimpleTopic.notify(__SimpleTopic.java:112)
at
org.globus.exec.service.exec.__ManagedExecutableJobResource.__setState(__ManagedExecutableJobResource.__java:909)
at
org.globus.exec.service.exec.__processing.handler.__CleanUpStateHandler.process(__CleanUpStateHandler.java:56)
at
org.globus.exec.service.exec.__processing.handler.__InternalStateHandler.__processInternalState(__InternalStateHandler.java:49)
at
org.globus.exec.service.exec.__processing.StateMachine.__processInternalState(__StateMachine.java:121)
at
org.globus.exec.service.exec.__processing.__StateProcessingTask.run(__StateProcessingTask.java:82)
at
java.util.concurrent.__ThreadPoolExecutor$Worker.__runTask(ThreadPoolExecutor.__java:886)
at
java.util.concurrent.__ThreadPoolExecutor$Worker.run(__ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.__java:662)
<...snip...>
The VM has a static IP. Have you got any clue for me on what could be
the problem? Anything else I should provide for analysis?
Thanks,
Timo
--
--
Timo Henne
Research and Development Department (RDD)
State and University Library
Georg-August-Universitaet Goettingen
37073 Goettingen
Germany
Phone: +49 551 39 3883
http://www.sub.uni-goettingen.de/
