By using this website, you agree to our Terms of Use (click here)
It seems like every technical question I ask on the official Acumatica forums gets met with crickets, and I know everybody here is smarter than I am. 🙂
Is there any rule of thumb of what within a customization that will cause it to trigger a restart, vs. publishing in real time? I have read that there is a web.config option (we're hosted, so I don't have direct access) that will cause any Publish to cause a restart.
I'm running into a really strange issue and Acumatica support hasn't been able to help out at all. I have a few customizations that I'm attempting to roll out updates for. None of them are invasive; I have three standard packages that I use in our business for:
* User Fields (adding to database, and if it's a basic DAC addition, adding to the DAC)
* Code (75% of this is more advanced DAC additions, like tying the schema of a user field to a selector)
* UI Changes, such as sidepanels on forms, adding user fields to forms, updating workflows, etc.
This week I tried publishing these, and after it completed and I did a restart in the Apply Updates screen, my Process node was not accessible (for the most part--I could sign in, and get the banner at the top of the screen, but no screens would open and no scheduled jobs would run). I backed out the customization updates and the process node was accessible again.
Last night I tried publishing one of these at a time (in the order above), and the Process node was accessible up until the final one. Backing out the final customization didn't make it accessible, but when I backed out the Code package it became accessible again. My theory is that, if a customization tells everything behind the scenes "You need to restart", it makes the process node accessible, and the UI Changes customization doesn't trigger that. I'm thinking of putting some sort of code change in the UI Changes package to see if that triggers the "You need to restart" rule, but that's just a guess.
I will say that this update to the UI Changes package is the most complex I've done; I've started doing more in the Workflow editor to do things like set default values on fields when orders are created, released from hold, etc. But all of those changes test in our sandbox cleanly and even work on the main front end node in Production.
We have a client that has a processing node and were running into issues with customizations. Since they use the SAAS version we had to work with Acumatica to update the config file so that it was NOT in multisite mode. Once they did that we then had to start publishing customizations in their main tenant and then publish them in the Processing Node.
The client was was running 2024 R1 at the time and there were apparently some issues with the multisite mode. I am not sure if Acumatica has fixed the issue as we still publish in the sites separately.
@sljeter Interesting--I asked Acumatica about being able to do this (I had a consultant tell me that it was available previously) and they said that was no longer an option. I'd love to turn off Multisite for our environment because we have a couple of Process screens that don't seem to cleanly publish to the Process Node, so my publish process always involve publishing to both nodes anyway.
@tlaird That is interesting. What version are you working with? We are getting ready to start testing for their upgrade 2025 R1 and it this feature is no longer available that may make things more interesting.
@sljeter Currently on 23R1. We are upgrading to 25R1, so it's possible they were referring to that...but what's more likely is that the person in support I was working with doesn't know the option exists.
@sljeter Are there any other downsides to having the nodes not in Multisite? Like I mentioned, I already have to publish customizations to both because of a couple of screens that don't seem to update otherwise.
We're doing more with external connectivity, and every once in a while an external service will run a crazy GI that maxes out memory on the process node and causes a restart. And since they are in multi site mode, when the process node restarts, it restarts the primary node as well, which defeats some of the purpose of separating out those workloads.
Apparently this is a known bug fixed in service packs and in v24R2 and beyond. I had to have the SaaS team do a restart of the IIS app pools on the process node.
Another reason I may move to self hosting--this is a really simple thing to do...if you've got access. As a SaaS customer I don't. So we opened a ticket for the SaaS team to do a restart at 7:45pm (Pacific) last Friday. I had asked for 8:30 but that was outside of the hours for standard support. They didn't do the restart at 7:45pm. I emailed my support engineer and the SaaS engineer asking why it hadn't been done. They told me that it had been done...2 minutes after my email (around 8:15pm). Frustrating that I have to babysit support teams for something that would take me 15 seconds if I had server access.
But it did resolve the issue--Saturday morning I published all of my customizations and everything went in without a hitch.
OK, one more update. This creeped up again this weekend. Resetting the App Pools didn't fix it. We tracked it down to two customizations both having files with the same names. Thankfully the support person I was working with Sunday night/Monday morning looked at the actual IIS errors and the code folder and let me know that he thought a file was missing. That got the lights to click.
The two customizations were one of mine, and one from our VAR. I copied the logic from the VAR customization (using an attribute as a schema for a user field), including adding a Constants code file with a constant for the name of the attribute. The VAR named their constants code file "Constants", so I did the same. This all started when I rolled out that first update with the Constants file, and backleveling seemed to fix it because I was going to a version without it. Both customizations now have prefixes on their constants files and all is well.
We did set both nodes up to not use shared customizations (so apparently that is an option still) and now I can manage each separately.