Server Queue Full - a solution

This would help prevent situations like this from happening in the future, along with making repetitive use so much more time efficient for everyone forging.

Continuing the discussion from Top Wanted Features from Glowforge / Begging Session:

Glowfrog approves


Is the Server Queue currently full?

1 Like

seems like it is processing jobs ate close to “normal” at the moment. ( just started an 8 minute ish cut and it flowed smoothly with very little lag).

I haven’t run into this problem yet but I can definitely see myself being pretty salty if I ever do. I only get a short amount of time per day to work on the GF, so if the great Cloud™ deems that it cannot process my job because it’s queue is full… well then we got a problem. So the ability to “preprocess” jobs would be at least a partial work around for some cases. They need to look into this quite seriously if the queue full thing becomes an issue that pops up more often.


My prediction: never going to happen.

I may be wrong, but I just think it’s a dead end. Besides, it is almost never an issue, and we’re not even sure what the problem was in this case. It may have had nothing to do with actually being overloaded.

It was a pretty big issue yesterday

I agree. Probably won’t happen. But eventually they NEED to look at allowing offline use of the machine. One of the (admittedly many) selling points when I went to buy the GF was that they had said they were going to open source it so people could write software for it that wouldn’t keep it tied to the cloud. I just don’t want to wait until it becomes necessary for that to happen before it does happen. No matter how much we want to think otherwise, companies pop up and die often. And hardware that is tied to a service with those companies becomes a boat anchor (I did NOT say paperweight, people… I didn’t. :smiley: ) Just look at all of the 3rd party NEST hardware that relied on NEST’s cloud service integration. Once google bought them and got rid of that cloud service… POOF. Every one of those devices became a pretty decoration for people to sit on an end table and wonder where their money went. Not to mention the companies that lost revenue streams practically overnight. Things happen and we don’t want to be suddenly sitting on the outside looking in, wondering if someone is going to be able to successfully hack the hardware to allow us to use GRBL or some such software.

(Disclaimer: everything in my reply is opinion)

No they don’t. You want them to, but that doesn’t mean they need to.

[“it” being the firmware, not the server side processing routines, so it’s kind of not what you want] They did. It’s on the forum. It’s hard to search for it, but it’s out there… it just came up recently, Jules produced the link from the ether, I think. Hunt around if you haven’t seen it.

True, but this wouldn’t be GF’s problem. Companies aren’t your friends, they don’t owe you much of anything. If GF went out of business tomorrow, they wouldn’t be on the hook for anything, they don’t have a contract with us.

Some lawyer somewhere would probably take on the case and try to extract some cash out of the situation, but I wouldn’t hold my breath. You’re talking about a company that doesn’t feel like it needs to provide itemized invoices on repairs, you really think they’ll get too upset if we wish we could do stuff offline in the event of their demise?

1 Like

Was a major issue yesterday

Right. That is what the server was reporting. Doesn’t mean it actually was under that much load.

Not sure what architecture they use but there have been bugs in nginx before that reported that even when the server was ok.

It would be incredibly smart for them to do this though.

One of the biggest stated detractors of purchasing a glowforge is the online component and the possibility of not being able to use your forge due to an outage.

This possibility is now becoming a reality after multiple instances of service being unavailable.

Not only that, but unnecessarily repeating compute intensive work is one of the biggest taboos in computing.

Providing customers with the ability to skip long waits to do their work, while simultaneously reducing queue times for others, as well as heavy compute expenditures, would be a big win for everyone.

To give a little more context my most commonly used job takes ~10 minutes to render server side. I run this back to back to back most days.

If I had the ability to cache that job, it would save them ~2hrs of compute time per day for just me. It would save me 2 hours of waiting, and reduce their queue by a fair percentage.


Saving the instructions locally and reloading the same job would seem to be a good move. But decentralizing the processing of the job is just not something they seem interested in doing.

It’d be tricky to be sure it’ll work with changing materials: say you save the job to work with proofgrade maple, but they change their supplier, now your settings are all wrong. They aren’t terribly incentivized to do a lot to support non PG materials, as much as we might like it…

They want it to be a “push the button and it just works” kind of moment, and the more complex you make this the less it becomes that. Look at the wide array of people complaining about how it’s too complex as it is.

Again, I really do agree with you about caching, either locally or on their server, but I still wouldn’t hold my breath. (if it were me, I’d do it serverside and store a serialized array of the settings passed from the UI and a checksum of the uploaded SVG (after mods in the ui of course). I’d compare that info to recent jobs (say the last rolling month) and if I have a match just spit out the saved processed file. But I don’t work for GF so…)

1 Like

It was also what a number of users were reporting who couldnt do their work.

Oh also, this. Yeah this is a detraction for some users, but the bulk of users don’t even think about it. That’s the best part: nothing to install, nothing to update, cross platform craziness. That’s a win for a huge swath of users and definitely for glowforge support.

Rando: “I have windows ME running on an overclocked atari 2600, do you have drivers for this?!”
Glowforge: “Get out of here with that driver business!”

1 Like

Right, but only the SA can say for sure is my point. I somehow doubt GF system administrators are going to tell us.

It doesnt have to be locally saved, it can be cached server side and just redistributed to the unit that requested it.

They can just attach material type meta info to the saved job (which it will already have anyways), so if they are aware of a material change, just re-render. A couple lines of code maybe.

To a user the only difference the user should notice is that some of their renders are instant instead of taking a long time. I cant see how that breaks the ‘push the button and it just works’.

Its not really a problem that has a huge impact on my business personally, as I have other lasers. As someone who has good visibility to a large portion of their community, not only am I in a good place to make this suggestion, but also to inform those not familiar with the workings of these services, how things in the background work, and what potential solutions could be. Furthermore, once they are aware a better solution may exist, if they put their voices behind it, they could potentially influence glowforge to move in a direction that is in the best interest of everyone.

1 Like

I actually LOLed at this.

I’m sure this is in the hopper, though, so… yay?

1 Like

Its happened multiple times in the glowforge history since ive been around.


Same, it would be easier to just purchase Glowforge than get them to listen to the community at large.

As long as an online app fits their business model and has more benefits than negatives, there doesn’t seem to be enough incentive to offer a stand-alone app that would need to be able to work on all the computing platforms that folks are using at the present moment.

I think @takitus’s solution seems reasonable, to at least be able to open stored jobs and print them locally. That seems like low overhead.

Still, I just take the online app for what it is worth. There will be issues, but it doesn’t come near close enough to erase all the benefits of having an app that is lightweight and doesn’t require me to do any local configuration.

But we have had this conversation before and it will go the same way at least for the short term.