On OSX. Leave mini-map enabled. shutdown monitor, repo upgrade from beta 11 > beta 12. Re-open monitor (auto-upgrades itself). Click on node view. mini-map is still displayed, but the icon button is no longer GREEN. Turn the mini-map off and then back on again and it’s back to normal business.
Select a job in job list, go to node view, use zoom [-] or zoom [+] buttons on top-right corner. go back to job list, de-select all jobs, so no job selected. Go back to node view and it has a vertical scroll bar present down the right-hand side. If I now press zoom [+] nothing happens, but if I press zoom [-] button, it cleans itself up and the vertical scroll-bar disappears. Minor issue, but could we clean this up, so if no jobs selected; ie: nothing visible in the node view, then there shouldn’t be the need for a scroll-bar in vertical or indeed horizontal?
“The web service no longer caches data from the database to reduce memory usage.” - Does this mean, we will now see longer Deadline Mobile refresh times?
OK, I was only able to get this error message once in console to appear. I’m unable to re-produce it so far:
2013-11-28 10:33:05: Error occurred while updating task cache: Argument cannot be null.
2013-11-28 10:33:05: Parameter name: key (System.ArgumentNullException)
The issue, is selecting a job and it fails to display any “task list” information. It’s left displaying: “Loading tasks…” in the task list. RC job, change status and then flick it back again and that seems to fix it. I thought it was a job that is archived and re-imported back in and then messed with it’s status, but that didn’t re-produce it, so I’m lost on this one for the time being. This error was on a custom plugin type which has only 1 task = 0 (1 frame). However, as I can’t re-produce it, I can say if this makes a difference!
It really depends on the number of jobs in the database. In a test with about 3000 jobs, I didn’t really notice much of a difference. There has been talk here about splitting the web service from Pulse, which would have 3 benefits:
Web service queries wouldn’t impact Pulse’s performance.
Web service scripts that cause crashes wouldn’t bring down Pulse.
We could probably consider caching the data again.
If we did this, it would be in Deadline 7 at the earliest. For now though, we had to take out the caching because it could cause Pulse’s memory usage to get quite high.
This should be fixed in beta 13. It happened to me yesterday, and I think I tracked it down. Because it can’t be reproduced reliably, it’s hard to say if it’s actually fixed, but I haven’t seen it since…
Standalone Pulse web-service; I guess wrapped around another executable does make sense. The number of users using the web-service is probably low, so most users won’t want/need to run this additional executable, although a level of failover/redundancy would also be nice for it. Similar to Pulse requiring failover redundancy. Also, better security if you can sand-box the web-service exe, although we can already talk to it via a proxy/IIS so no new functionality there really. Off-load the Python API service as well to this other exe?
Hmm…so if a bad pulse web script or a Python API script gets executed at the moment and causes an error/crash, it will take down both the Pulse web service and stop the API service from working as well?! Maybe 2 http services running over different ports in the future for better redundancy?
We actually want to start sandboxing python scripts by running them in separate processes. That way, a bad script could never take down the main application.
Hey Mike,
For #1 this is what I would expect to have happen currently since the zoom all functionality zooms out till the full scene rect is fully visible (aka you will be fully zoomed out so no scrolling), and the other one zooms till all objects bounding boxes are seen (if there are no items then do nothing). The main thing with this which we have not figured out how to handle it ( or if we are going to even) is that the scene will never shrink and will grow automatically, we have not found a way to handle this otherwise without completely destroying the scene and creating a new one which we do not want to do since it could be slow.
for #0… no idea, if you leave the minimap on, when you close and then open normally does it work fine? If so then I am just not going to worry about it since it is a visual bug on upgrade only.
@Ryan
I now have a reproducible pattern for issue #3 from yesterday. A suspended job is resumed. The single task/frame job completes and the task is marked as complete. The job status then changes from “rendering” back to “suspended”! If you click off and back onto the job, you get this in the console. It’s on a custom job, so if needed, I can archive the job and also send you the plugin as well if needed.
2013-11-29 16:47:35: Error occurred while updating task cache: Value cannot be null.
2013-11-29 16:47:35: Parameter name: key (System.ArgumentNullException)
Do you remember if that particular job originally had Pre & Post Job scripts, that were then removed? I’ve been trying to reproduce this for a couple days, and I was finally able to do it by adding pre/post job scripts, doing a bunch of shenanigans, removing them, and then letting the Job complete. I’m really hoping that’s what happened to your job so I can stop busting my brains on this one
Nope, I have never touched pre or post job scripts with the 2 jobs I have in my queue which are in a strange state. (ie: all tasks completed but job status is suspended).
Here is the job history of the 2 jobs if it helps to track it down at all. The common theme for me was I archived the jobs in I think either all completed or all suspended state and then re-imported the jobs, re-queued them, etc as per the history log.
