I have made a flutter app which gives notifications whenever I get an error on the machine running embedded. The way I achieved this is by posting the error on the hosted webserver's page every time I have an error, and then the moment the error is resolved, removing it from the page. Meanwhile, the flutter app connects to this webserver page via the ip address using http request and then refreshes it every second to see if there is any data. If there is, then it sends a notfication on the phone, and starts comparing the data every second to see if any change happens. If the data is changed, another notification is sent else it keeps on refreshing the page and reading it.
The program I used to write the error to this webserver is through C++ code which opens the index.html file, performs write operation and then closes the file every time a new error occurs. The moment, the error is resolved, the file is again opened and the record is deleted making the index.html blank and ready to receive another error.
I want to know if there is any better way to achieve this so that the page only refreshes on new data arrival. As I have been told, refreshing the webpage every second can cause extra pressure on the embedded processor it has been hosted on. Any leads will be appreciated.
Thanks for your time ^^.
We are seeing a random error that seems to be caused by two requests' data getting mixed up. We receive a request for quoting shipping costs on an Order, but the request fails because the requested Order is not accessible by the requesting account. I'm looking for anyone who can provide an inkling on what might be happening here, I haven't found anything on google, the official flask help channels, or SO that looks like what we're experiencing.
We're deployed on AWS, with apache, mod_wsgi, 1 process, 15 threads, about 10 instances.
Here's the code that sends the email:
msg = f"Order ID {self.shipping.order.id} is not valid for this Account {self.user.account_id}"
body = f"Error:<br/>{msg}<br/>Request Data:<br/>{request.data}<br/>Headers:<br/>{request.headers}"
send_email(msg, body, "devops#*******.com")
request_data = None
The problem is that in that scenario we email ourselves with the error and the request data, and the request data we're getting, in many cases, would've never landed in that particular piece of code. It can be a request from the frontend to get the current user's settings, for example, that make no reference to any orders, nevermind trying to get a shipping quote for it.
Comparing the application logs with apache's access_log, we see that, in all cases, we got two requests on the same instance, one requesting the quoting, and another which is the request that is actually getting logged. We don't know whether these two requests are processed by the same thread in rapid succession, or by different threads, but they come so close together that I think the latter is much more probable. We have no way of univocally tying the access_log entries with the application logging, so far, so we don't know which one of the requests is logging the error, but the fact is that we're getting routed to a view that does not correspond to the request's content (i.e., we're not sure whether the quoting request is getting the wrong request object, or if the other one is getting routed to the wrong view).
Another fact that is of interest is that we use graphql, so part of the routing is done after flask/werkzeug do theirs, but the body we get from flask.request at the moment the error shows up does not correspond with the graphql function/mutation that gets executed. But this also happens in views mapped directly through flask. The user is looked up by the flask-login workflow at the very beginning, and it corresponds to the "bad" request (i.e., the one not for quoting).
The actual issue was a bug on one of python-graphql's libraries (promise), not on Flask, werkzeug or apache. It was not the request data that was "moving" to a different thread, but a different thread trying to resolve the promise for a query that was supposed to be handled elsewhere.
I have a particular scheduled task that CF claims runs every 2 minutes. However, it either doesn't run or complete since the database changes the task is supposed to perform do not occur after each run. However if I copy the exact same URL into a browser and run the script, it works 100% of the time.
I have no clue where to start debugging. There is no IP restriction on the page.
I can see in the CF Admin that it was last run at 2:06 for example and the next run will be at 2:08. I can also see it in the scheduler.log file.
We had updated our certs in IIS but didn't update our cacerts file. Once we did everything was great.
It was clear the process wasn't running when I added a line or two to email myself at the start of the task. The emails never came when the server ran the task but they did when I pinged the page. I changed the task to save the output to a log file and when I opened that up it just said "Connection Failure". This led me to some googling and some talk about certificates which made me remember that we just updated ours recently. Looking back at my emails with IT it did indeed happen on the same day that the last emails in the mailsent.log were sent from these scheduled tasks.
I am at my wits end on this and can't figure this out. In sitecore v6.2 something has changed that is causing an error message as follows
"The operation could not be completed. Your session may have been lost due to a time-out or server failure".
looks like this is coming from Sitecore.Web.UI.Sheer.ClientPage?
The request info:
https://sitecore.test.domain.com/sitecore/shell/sitecore/content/Applications/Content%20Editor.aspx?ic=People%2f16x16%2fcubes_blue.png
the response:
{"commands":[{"command":"Alert","value":"The operation could not be completed.\n\nYour session may have been lost\ndue to a time-out or a server failure.\n\nTry again."}]}
At first, I assumed it was because plugged in some new HttpModules so I moved them into the sitecore pipeline model and the problem kept persisting. I removed them from the entire application and the problem kept persisting.
A google search on the error gets me to some information on the keepalive.aspx stuff, but addressing that has no bearing.
I decompiled the code with reflector, but can't find anywhere this particular error is raised. It must be in sitecore.nexus or something.
According to my superiors we will open a ticket once we get the build resolved, but here's to hoping someone here has some suggestions.
The constant for this error message is THE_OPERATION_COULD_NOT_BE_COMPLETED_YOUR_SESSION_MAY_HAVE_BEEN_LOSTDUE_TO_A_TIMEOUT_OR_A_SERVER_FAILURE_PLEASE_TRY_AGAIN
This might happened if you server restarts while some dialog opened
I am having a strange problem with my SMS Gateway. The SMPP connection to the external gateway is fine, and outgoing messages are never a problem.
The problem is to do with my incoming.cfc - the gateway instance points to "incoming.cfc" and that file is set up to send an auto reply to the incoming message and add some details to a database. Simple and it works as tested.
Every couple of days though the incoming messages stop getting added to the database, and the auto reply messages don't get generated. The log files indicate that (although no changes have been made to either the incoming.cfc file or any other files or configuration settings) we have somehow "switched back" to an earlier version of the incoming.cfc file - I can tell this because the wording of the return message in the logs matches this earlier version.
I have read Adobe documentation that says the gateway will use whatever incoming.cfc it is pointed to and you don't need to refresh the event gateway instance if you change the cfc - even though the old cfc has been deleted off the server entirely and the new one not changed - when the problem occurs (every other day) an instance refresh appears to fix it.
Has anyone seen anything like this?
Thanks for listening!
Simon
Try renaming your cfc from incoming.cfc to incoming2.cfc