Inspiring

Question

CFAdmin's new Scheduled Task system Fails at Everything

Forum|Forum|12 years ago
July 31, 2013
2 replies
2608 views

So about a month and a half ago we switched from CF9 to CF10, and we were excited about what new features we would find in the revamped Scheduled Tasks section. As it turns out, our optimism and faith was severely misplaced. In every single aspect of the scheduler product, Adobe fails to deliver a usable product, and in most cases takes severe steps backward.

Did you copy over your old neo-cron file so that you wouldn't have to set up 50+ tasks by hand?

Well lucky for you that all the tasks will now be in CAPS for some reason, and every one of them is labeled as "paused" even though they are currently running.

Did you like how nicely CF9 grouped the tasks by type, sorting hourly, daily, and weekly tasks into groups?

For your convenience, that's now gone.

Would you like to change the name of your task?

Sorry! Error Message: It is unable to store the job because one already exists with that designation.

Would you like to change what URL is called on the task?

Sorry! Error Message: It is unable to store the job because one already exists with that designation.

Would you like to start up a finished scheduled task again on a different date?

Well we can do that, but we refuse to give you any indication that it's actually been scheduled.

Would you like to create a new task?

We'll do that for you, but we won't show you the task in the overview. You'll just have to wait until the first time it runs and then it will magically appear.

Would you like to delete a task?

Sorry! Unhandled Error: The following task could not be found.

Seriously.

This is the most unusable piece of garbage I can ever recall seeing. I have been using ColdFusion since version 4.0 and I have never been this mad at it. What is the point of out-sourcing your scheduler to Quartz if it doesn't work?

This topic has been closed for replies.

tribule

Legend

I'd agree with ColdFusion Smurf, we've had no end with the scheduler in CF10. It throws very strange errors and sometimes will not allow us to rename a task or create a new one. Also today, it ran all our tasks at once!

Is there a replacement for the CFScheduler that one can use?

Charlie Arehart

Community Expert

Smurf, before addressing your issue, I want to point out first that it’s never been recommended to copy neo xml files from one instance of CF to another, let alone from one version of CF to another. I realize you may feel that you or others have “done it for years without problem”. It still was always risky, and it’s all the more so with scheduled tasks, because CF10’s support of them is in fact really quite different, due to the quartz-based implementation that you refer to, and the xml files from 9 just are not the same as what CF10 would build.

Now, should Adobe have warned you of that? Well, I’d argue not, because again bringing forward neo xml files was not something that was ever really a supported approach to migration. They would instead propose using the ColdFusion Archive (CAR) mechanism. Of course, that’s only offered in CF Enterprise, Developer, or Trial editions, not in CF Standard, which is its own debatable and lamentable topic, for another day.

Even if one felt they had no choice (especially lacking the CAR mechanism) but to try to copy neo xml files between editions, an argument could be made that one should certainly be prepared for possible errors (and so should keep a copy of the original xml file from the new release, in case they may need to revert to it.)

Sorry that this may sound a bit like scolding. I don’t mean that. I’m just offering what I hope is helpful practical perspective on the annoyance you experienced.

And really, it then leads one to wonder if all the rest of the problems you hit are related to that issue? Can you clarify: did you experience all your other issues (from changing the name, down to deleting a task) on a CF10 installation where you had NOT tried to do that import? It would be helpful to hear. I mean, I have not heard others complaining of this issue, and it seems reasonable that if it was all wholly busted as you propose, that certainly others should have reported it by now.

Again, I hear your frustration, and I risk only raising it and your ire. Please hear me right: I appreciate your dilemma. I’m just trying to help you and also future readers to know if the problems you’re hitting are really all about CF10 simply sucking at scheduled tasks, as you assert (if I could word it differently). I am inclined to think there’s another problem at issue for you.

Finally, and perhaps most important: are you in fact referring to a CF10 with all updates applied? I realize it may be seem obvious that you have. But even if you’d say yes, is there any chance that you have more than one instance that you’ve implemented within CF10 (available if you’re running the Enterprise, Trial, or Developer edition)? And if so, might you perhaps have updated one instance but not the one against which your code is running? Here’s a quick way you could test: do a CFDUMP of the server scope. It will report the version, and as of CF10, that now includes an indication of the update level, as the 3rd number, so that 10,0,11 means it’s CF10 running its update 11.

Hope that’s helpful. If I’ve still only served to raise your annoyance, please work with me to try to forgive it, and help correct where I may have failed you. I really am just trying to help, you and other readers.

/charlie

/Charlie (troubleshooter, carehart. org)

ColdFusionSmurfAuthor

Inspiring

It is interesting to me that you say it is not recommended to copy the neo-*.xml files from one installation to another. We've been doing that regularly since MX and we've never encountered a problem, at least not until this scheduler issue perhaps. In fact, it seems more than a little surprising to me that you would actively suggest to NOT do it. Copying those configuration files seems like the safest way to ensure that your server configuration remains standard across installs, and all test machines in your environment.

And I'm still not sure I'm sold on the idea that everything will start working again if I just roll back my scheduler to a blank file. For instance, why would an XML config file disrupt the scheduler's ability to delete a task?

Honestly, most of the errors lead me to believe that Adobe is storing the scheduler data by task name, instead of some independent UUID. Every error I get says something like "I can't create that task because one with that name already exists" or the like. That just seems like really crappy programming, not a config file problem.

And yes, my server is up to date.

I honestly don't know why it would only be happening to me, but after all the problems we've had with CF10, I'm no longer willing to lay the blame at my door. Once upon a time I would have given Adobe the benefit of the doubt, but they've pretty much proved they don't deserve my faith any more.

- How is it exactly that half the stuff they fixed in update 11 wasn't in update 1 or 2? How did stuff like this make it over a year before it got fixed?

- Why is it that the 404 error handler (hanging processes) issue still isn't fixed, even after applying the update and redoing the connectors? Why is it that they have yet to acknowledge that the error still persists?

- How did that web socket security issue ever make it through testing? I mean, seriously? In a version that was touting its added security benefits? You are opening up a new way to access components and no one thought to check that you could only run the ones you were supposed to be able to? I pretty much can't trust any security claims CF makes from this point on if this is their level of attention to detail.

--------------

So thank you Charlie for your kind response. I suppose at this point I have no recourse left but to re-build the scheduler from scratch. I guess I'll try that.

Charlie Arehart

Community Expert

Well, to be clear, I anticipated that (“I realize you may feel that you or others have “done it for years without problem”).

As for your surprise that I would even suggest against it, I thought I was also clear: Adobe would say that you should use the CAR mechanism. But granted, those on Standard couldn’t, so they may have resorted to copying the xml files. That doesn’t make it right or recommended.

And yes, I would recommend against it, for three reasons:

- again, in copying between versions, the xml for one may not all apply for another

- and in wiping over what was in the one system with the file from the other, you may either lose values from the new one, or lose changes to the xml placed there by the new version

- finally, even in copying between two CF instances of the same version, there could still be values in the old file that were specific to that old instance, which may not be appropriate on the new

So could one be really careful in doing such a “manual migration”? Sure. But it’s not even easy to do a compare of the files, perhaps to surgically merge in values from one instance into the other, because as you may have noticed, the neo xml files are in wddx format, which means they are both minified and have no fixed order, so most compare tools can’t really compare them effectively.

As for your observation that it seemed the best way to ensure consistency, well, again, you may have been able to do it between systems of the same version, if you confirmed there was nothing instance-specific (or you tended to it). I’m just saying that no, it was not a generically supported notion that one should do that, even if people did do it. But we’ll call that just my opinion. You and others may disagree.

Moving on to how to proceed, you say you’re “not sure sold on the idea that everything will start working again if I just roll back”.

Well, I had actually asked first, “Can you clarify: did you experience all your other issues (from changing the name, down to deleting a task) on a CF10 installation where you had NOT tried to do that import? It would be helpful to hear”.

But if the answer is no, then back to your wondering about rolling back, I would ask, why not try it? If it works, you can then put a single task in manually, and compare how the xml file differs, to see what was amiss. Again, I would not be surprised that the scheduling xml is just very different in CF10 than before. And here’s something to consider: even if you are not using the “new” features in your “old” scheduled tasks, perhaps there’s no difference in the xml related to any one task, but there may be one or a few new xml elements that needed to be there which CF10 would have put there, but you wiped out in your copy. It’s worth checking. Then you’ll know how big a deal it may be.

And you may then also answer your question about whether it’s a difference about how they are keying the tasks within the file? Bottom line: why bang your head on this wall? I think you may just have to accept that the file is different and you can’t just drop an old one in its place. Figure out the differences, and press forward.

Hope this has been helpful in encouraging you toward this. I’m sure if you offer a reply with your findings, you may help others who find this discussion in the future.

To your last points, well, I can’t restore your faith in Adobe. I’ll only say I don’t share your dismay and concerns. As for your last questions:

- as for why “half the stuff they fixed in update 11 wasn't in update 1 or 2?”, well, I don’t know about EVERY fix in update 11, but certainly some wouldn’t have been fixed in update 1 or 2 because a) they may not have known the problem existed, b) they may not have known how to solve it, c) they may not have been able to solve something because of something related that was not fixed until some later fix (5, 6, or 7, for instance). I’m just guessing on all that. And I realize it may ring hollow if you have lost faith. I’m just offering a different perspective.

- as for your assertion that “the 404 error handler (hanging processes) issue still isn't fixed, even after applying the update and redoing the connectors”, well, it is fixed for some people after that. As for any still suffering, you ask why Adobe doesn’t acknowledge it. Are you positive that they know of it? Are you referring to clarifications someone has offered in a bug report (after the update came out)? Or a comment in the forum (which of course there’s no guarantee Adobe will read)? Again, not trying to be argumentative. Just trying to advance your cause.

I’ll add this also: I help people solve problems with CF and IIS every day, and I have seen plenty of instances where the person’s problem was because they were manually tweaking things (in desperation, perhaps based on tweets/blog entries/forum threads they’d read) and they’ve just made the lumpy bed they’re sleeping in—and blaming Adobe for. Tell you what: if you know any one person with the specific problem, I’ll offer an hour to look into it with them, to see if it’s a problem with IIS, connector, or CF configuration. If not, and it seems then clearly that it must be some real CF bug, I won’t charge for that hour.

As for your last point, I’ll only agree with you that it’s a shame that they didn’t think to test for this. But hey, I can’t cast the first stone. I’ve surely forgotten to test something which I should have (whether in defensively programming an app, or setting up some new security protection on a server). They’re human, they made a mistake. It was found, and corrected really quite quickly. I guess I choose to look at the glad half full, but I know others do see many of these things differently. I just keep trying to help, and offer a more positive perspective when I can and it seems warranted.

Hope something there’s helpful.

/charlie

/Charlie (troubleshooter, carehart. org)

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded