Hi, Are there plans to make Planetpress Workflow into a 64 bit application?
The ongoing issues with 32 bit memory limits is really frustrating.
2 Likes
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.
Hi,
Also just jumping into this. Searching the forum for “Out of Memory” yields a very long list of posts about this limitation. And the issue is dated years back and its already 2024. For many customers who are heavy workflow users and processing large volumes, this is one of OL Connects Achilles heels. And something that should have been the heading of the Connect Workflow guide. Something along the lines of "Workflow is 32bit be aware of its limitation…here are the things to keep in mind when designing your process… " etc.
Excuse me if I sound frustrated, its because its early in the morning(6:30am) here. And I have to check if my process has run out of memory again. And of course it did.
Now if I am to suggest to alleviate or ease the obvious frustrations, it would be wise to make transitioning from Workflow to OLCNRS as smooth as possible, talking about Plugin Tasks available in Workflow existing in OLCNRS, also we like the global script includes in Workflow as well.
As you mentioned having OLCNRS work side by side with Workflow is fantastic, Im picturing this as having OLCNRS handle some of the grunt of workload. Workflow can even have OLCNRS/Workflow plugin equivalent.
Im referring to having to rewrite all the work weve done in Workflow suddenly becoming obsolete when transitioning to OLCNRS. As this can be big seen as big insult to Workflow users. If we are to be told we have to scrape all of it.
I understand your frustrations and please trust me when I say that I share them as well. I have run into similar issues on - thankfully! - rare occasions, so I know the pain of having to shut down the service and hope my latest changes were not lost.
That being said, we are addressing the issue by working on a more modern, 64-bit, Unicode-compliant automation module named OL Connect Automate. It is based on Node-RED and it has already been successfully implemented in several of our customers solutions. Automate is already at the stage where it is much more than just a Tech Preview, but it is still missing a few features that prevent it from being a full-fledged replacement for Workflow. We are actively working on those missing features.
We may at some point provide a tool that would allow users to convert (in part or in full) an existing Workflow configuration into an Automate configuration. But it is not currently one of our priorities since both Automate and Workflow can run concurrently, on the same server, and split and share the workload easily. This already helps make the transition from Workflow to Automate much more gradual and painless than if we had to completely replace the former with the latter.
And by the way, adding external modules to Automate (i.e. an even more powerful feature than Workflow’s JS Includes) can already be achieved easily (re: Use any npm module in Node-RED), so rest assured that you will not be losing any functionality on that front, on the contrary!
I encourage you to explore the possibilities of Automate, it is freely available as a Tech Preview, doesn’t require any licensing, and it even has its own space in our forums. The more users we have trying it out ahead of its official release, the more feature-rich and issue-free it will be when we actually release it.
Thanks Phil.
I can still run big jobs in a way of splitting the process in workflow. But this needs to be handled manually.
As for the transitioning, I heavily use Workflows JS include and would be annoyed to not be able to utilize it in OL Connect Automate. Also I seen my colleague tried OLCA but since its not a fully release software yet. Many things can still change and we dont have luxury of time to allocate at this stage.
But it is definitely sounding promising.