Bug #5602
closedTimezone confusion using the scheduler
Added by Derik Barseghian over 12 years ago. Updated over 12 years ago.
0%
Description
It appears at least some parts of the Workflow Scheduling system don't account for different timezones. When you schedule a workflow in Kepler, you don't specify timezone, so presumably this is local time. I think the server also uses local time, and so this requires you to know where the server resides, and schedule using its time. Instead we should probably translate to GMT, and expose timezone codes in the gui.
Updated by Jing Tao over 12 years ago
We added two drop-down boxes for both the start and end time. Users can use the boxes to choose time zone names.
In order to avoid the locale issues, the time zone ids will be communicated between the clients and servers. I verified the time zones ids used English even though the machine had the Chinese Locale.
However, the time zone ids have a slight difference among different java versions. So it is possible that a server can't understand a time zone id from a client if their java versions are different. I had to add a new API in the Scheduler Server so client can use it to get time zone ids from the server. Those ids will be used in the communication. So this will make sure that server can understand the time zone ids. Also the client will cache those time zone ids in order to improve performance.
If there is no time zone id parameter in the client's request (e.g., kepler-2.3), the scheduler server will use the default value -- its local time zone.
I tested the new feature and it worked to me. I will leave it open until Derik tests it.
Updated by Derik Barseghian over 12 years ago
I tried testing by scheduling with kepler-dev, but i get an error which includes this text:
WorkflowScheduler.checkUserPrivilege - there is no user and group information from the remote session which was authenticated by http://kepler-dev.nceas.ucsb.edu/kepler/services/AuthenticationService.
This can be caused by the session from a Metacat which has an older version than 2.0.0. Please update Metacat in order to enable the access control.
Updated by Derik Barseghian over 12 years ago
Ben upgraded the kepler-dev metacat to 2.0.1.
After that the runengine was unable to run workflows scheduled by barseghian, giving this error:
[WARN] PWHandlerServer.handle - user uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org is not allowed to run workflow run engine. If you want it to run, please edit the wfWSProps.properties file.
[WARN] PWHandlerServer.handle - user uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org can't be authenticated : PWHandlerServer.handle - user uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org is not allowed to run workflow run engine. If you want it to run, please edit the wfWSProps.properties file.
So I changed workflowrunengine's WEB-INF/classes/wfWSProps.properties allowedRunningUser to:
allowedRunningUser=uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org:uid=tao,o=NCEAS,dc=ecoinformatics,dc=org
Now runs scheduled by barseghian are able to be run as kepler, and you're still not allowed to, from within kepler, schedule workflows as 'anon' (uid=kepler), which is good.
Scheduling in PDT and EDT timezones works as expected.
However the runengine is getting an NPE from reporting that needs to be looked into:
[null] Successfully exported to kar file: /usr/share/tomcat6/KeplerData/workflow-runs/testWorkflowWithReport-execId1_20120627-192828875PDT.kar
[null] java.lang.NullPointerException
[null] ReportingListener wrapup() - problem with kar and/or karXML uplaod.
[null] 1634 ms. Memory: 146304K Free: 108985K (74%)
[null] at org.kepler.reporting.ReportingListener.uploadFiles(ReportingListener.java:379)
[null] at org.kepler.reporting.ReportingListener.wrapup(ReportingListener.java:340)
[null] at org.kepler.provenance.ProvenanceRecorder.wrapup(ProvenanceRecorder.java:776)
[null] at ptolemy.actor.CompositeActor.wrapup(CompositeActor.java:2523)
[null] at ptolemy.actor.Manager.wrapup(Manager.java:1368)
[null] at ptolemy.actor.Manager.execute(Manager.java:389)
[null] at ptolemy.actor.Manager.run(Manager.java:1159)
[null] at ptolemy.actor.Manager$PtolemyRunThread.run(Manager.java:1689)
Updated by Derik Barseghian over 12 years ago
Hey Jing, let's discuss this bug when you get back.
Updated by Derik Barseghian over 12 years ago
Jing and I debugged tonight. The problem was the repository configuration.xml didn't include kepler-dev. It must've been that the one in KeplerData was changed, but then KeplerData got deleted, and was replaced by an unchanged version. Jing fixed the source version.
Last thing to check is bring webapp up to head, and try against sensor-view-0.9 (once it's complete, I'm going to merge in some more changes from today).
Updated by Derik Barseghian over 12 years ago
Closing, the workflow runengine and scheduler are working now w/ sensor-view-0.9. There were a few additional problems that Jing and I worked through -- the xlst to transform the reporting configuration.xml to change the value of uploadToServer needed to be made to work for the current reporting suite (not instead looking for "reporting-0.9.0"), and a change to accomodate metacat 2.0.0 permission changes needed to be merged into repository-2.3 (to be released as a patch) so that kar uploads can be publicly visible, if that's chosen.
(In reply to comment #5)
Jing and I debugged tonight. The problem was the repository configuration.xml
didn't include kepler-dev. It must've been that the one in KeplerData was
changed, but then KeplerData got deleted, and was replaced by an unchanged
version. Jing fixed the source version.Last thing to check is bring webapp up to head, and try against sensor-view-0.9
(once it's complete, I'm going to merge in some more changes from today).