Hi, Are there plans to make Planetpress Workflow into a 64 bit application?
The ongoing issues with 32 bit memory limits is really frustrating.
Workflow 64 bit
1 Like
We decided against converting Workflow to 64 bits because it would require us to change the entire development environment, which is almost the same as a complete rewrite.
Instead, we decided to develop on a Node-RED based version, which is natively 64-bit and Unicode-compliant. We already have a version - the OL Connect Node-RED stack (OLCNRS) - that can be used for most standard Connect operations. Our goal is to have a fully-featured alternative to Workflow within the next 18 months or so.
We already have a User Forum dedicated to questions about this. In the sticky post at the top of that forum, you will find links for downloading and installing OLCNRS.
Note that we are still actively developing Workflow, but we are simply not converting it to 64-bit/Unicode.
Thanks Phil.
I’ll starting looking into it.
Hi @Phil
Will there be an upgrade path for the alternative workflow or will it require to be started from scratch.
Also I’m not really sure what this OLCNRS is? Is it something to use instead of workflow?
James
At this stage, OLCNRS can be used as a complement to Workflow. In some instances, it can even be used instead of Workflow, but to be honest, it doesn’t yet have all the functionalities that have been built into Workflow over the years. But for basic OL Connect operations, it already works very well.
In cases where, for instance, you are running into Workflow issues (32-bit, or lack of Unicode support), then using OLCNRS side-by-side with Workflow can be quite a handy solution.
We want to beef up its functionality so that at some point it will become a full-flegded replacement for Workflow, but that’s still a long way off on the horizon.
This is getting rather frustrating with this whole 64bit as I have 4 developers working constantly all day using workflow having to press save after every single change they make and constantly loosing time having to close and re-open workflow which means development is taking far longer than it should be. I can’t honestly believe that nothing has been done about this yet. I’ve tried reaching out to my account manager but since the most recent take over everyone seems to have disappeared from account management
I’m going to have to start to look at other options for software I think as I have no confidence this fundamental flaw which is causing so many customers the same issue and has been for several years but it’s still not been resolved. I’ve heard a large competitor that used to be know by 3 intials now offers a cloud based version which is very comparable on price rather than the old massive outlay you used to have to pay which is why we didn’t go with them
I am sorry you are running into so many issues with Workflow. The 32-bit limitation is indeed a major hurdle for those who run into it, but it is still a relatively rare occurrence. I am curious as to why your team would run into it so frequently. I am assuming it’s because you are constantly working with very large files, but maybe there’s something at play, here.
If you don’t mind, I’d like to reach out in private and perhaps we could schedule a live discussion so I can learn more about your predicament. Would you be open to that?
Hi Phil
Yeah I’d welcome that. We are working constantly within workflow as 95% of our work is automated. So while some files are large we do get it when we have running small files too. What I’ve seen it’s totally random and can happen more when you are doing a lot of running of small files while doing dev. We’ve also had the error come up when it does the autosave
Regards
James
Hi Phil,
I’m in the same boat as James and can completely relate to his frustration. I think you will find that any Workflow users that have more than a few processes and put it under load will have severe issues. I don’t believe any high usage customers have ever been asked and any feedback has been ignored. There are memory leaks everywhere which are compounded by the limitations of 32 bit structures. As en example it is common place for us to have to restart the service multiple times a day to clear the memory. If the memory hits 1G then the service becomes unstable and fails to process actions. Files are deleted and the services hangs. Only way to solve that is to reboot the entire server.
Like James, I would also love to help the new upland team resolve these issues so happy to provide feedback. Love the idea of a node red solution so we will installing that and seeing if we can move workloads over there to improve stability.