I have few Motorola FX7400 readers that read RFID tags on production line + app based on EMDK(EMDK for .NET v2.8) to fetch inventory data.
Randomly(?) some of readers stop to deliver correct tag inventory report and continously return "Report Buffer Overflow Error Event (251)".
What is the reason of such behaviour and how to solve this?
I am attaching Wireshark screenshot.
Related
I am using QFileSystemWatcher to control the log file changes.
For creating and updating the log file I am using boost library.
When I log few messages in one method file changing signal emits only ones (for last message), but I see that file updating every time after log message added.
So, the code for QFileSystemWatcher is
std::string fn = "app.log";
logging::init_log(fn);
QFileSystemWatcher* watcher = new QFileSystemWatcher();
auto success = QObject::connect(watcher, SIGNAL(fileChanged(QString)), this, SLOT(handleFileChanged(QString)));
Q_ASSERT(success);
watcher->addPath(QString::fromStdString(fn));
adding log messages
void a(){
/* some code */
logging::write_log("test error", logging::kError);
logging::write_log("test info", logging::kInfo);
}
QFileSystemWatcher emits signal only ones for Info level message.
In file manager I see that file updating after each call (test error, test info).
In log file initialization I use
sink->locked_backend()->auto_flush(true);
so the file updates immediately.
How can I fix this? Or maybe there is another approach how to handle log file updating to show message in GUI.
Similar filesystem event notifications are usually collapsed into one, unless they are consumed by a reader. For example, if the writer writes 10 bytes to a file, the thread that monitors that file for writes will typically see one event instead of 10. This is explicitly outlined in inotify description notes on Linux, which is likely used internally by QFileSystemWatcher.
This should not matter for any correct implementation of a filesystem monitoring software. The notification only allows the monitor to notice that some event happened (e.g. a write occurred), and it is up to the software to discover further details about the event (e.g. the amount of data that was written, and writing position).
If you aim to just display the written logs, you should be able to just read the file contents from the current reading position to the end of the file. That read operation may return one log record or more. It can return an incomplete log record, too, if the C++ standard library is implemented in a certain way (e.g. when auto_flush is disabled, and the stream buffer fills the internal buffer with part of the log record content before issuing write). The monitoring software should parse the read content to separate log records and detect incomplete log records (e.g. split data by newline characters).
I need to include a custom data object/JSON string with an error report, without losing the stacktrace that Stackdriver seems to capture. Setting a JSON string as the message doesn't seem like an ideal solution.
I have seen references to a jsonPayload key online, but haven't had success setting it in the report.
In the Node.js systems I am integrating Stackdriver into (via logging client), I have a logger function that accepts additional data about the environment, the error stack and any supporting data that led to the error, and I wish to include this with the report so that they can be quickly investigated.
I have instead had to use the Google Stackdriver Logging API to handle this in the interim, but I find the metrics viewer a little convoluted and it's also hard to keep track of which logs have been dealt with.
I saw a stale question on this previously, but didn't want to hijack it. Nor did it have any solution.
Hoping there's a solution!
What I do is storing custom payload to Datastore and put the link to Datastore viewer to the error exception message. Here is for example how it looks in Ruby (the method stores url and html strings that I need for debug as attributes of the Datastore entity of kind exception_details):
def report_error url, html
begin
raise "https://console.cloud.google.com/datastore/entities/query/gql?gql=#{
CGI.escape "SELECT * FROM exception_details WHERE __key__=Key(exception_details, #{
Datastore.save( Datastore.entity("exception_details") do |error|
error["url"] = url
error["html"] = html
error.exclude_from_indexes! "html", true
end ).first.key.id
})"
}"
rescue => e
Google::Cloud::ErrorReporting.report e
end
end
Here is an email I get:
Instead of clicking the blue button I visit the hyperlink where I can now inspect the html variable that I stored:
I see this error in a Liferay log file:
INFO [Incoming-1,liferay-channel-control,FOO03-38099][ClusterRequestReceiver:250]
Unable to find response container for b62ef2ea-00c6-11e8-ba89-0ed5f89f718b
When searching the Internet, there are only 7 results, mostly source code, plus 2 Liferay issues that seem to ignore the message.
My question:
What does this message mean really?
Can I safely ignore it?
The context you're describing doesn't contain a lot of hints as to when this is occuring. Due to the location of the code deep within clustering, it's quite abstract.
Based on the fact that
it's not an ERROR but an INFO
The comment on LPS-56376: "Has no real impact to system other than info level log messages stating: Unable to find response container for:... from ClusterRequestReceiver"
The title of LPS-56376: "ClusterableAdvice is not flagging methods that return void as "fire and forget""
and without deeper analysis, I'd ignore this message.
I am writing a component that reads data from a specific filetype. Currently, it has a property for filepath - I would like for this block to quit as hard as possible when passed an invalid file/no file found.
Throwing an exception causes it to stop execution, but also deletes the block from the chalkboard while I am testing (?), which makes me think there is a more "approved" way to do it.
My current solution is something like:
LOG_ERROR( MyReader_i, "Unable to open file at " + Filepath );
return FINISH;
Is there another way to stop if something is wrong, that will hopefully stop all downstream processing as well?
Have you taken a look at the Data Reader component in the basic components? It also has a file path as an input. It deals with this during the onConfigure call as shown below:
def onconfigure_prop_InputFile(self, oldvalue, newvalue):
self.InputFile = newvalue
if not os.path.exists(self.InputFile):
self._log.error("InputFile path provided can not be accessed")
And then again in the service function by returning NOOP.
def process(self):
if (self.Play == False):
return NOOP
if not (os.path.exists(self.InputFile)):
return NOOP
This isn't the only way to deal with invalid input however. It's a design decision that is up to the developer.
If you'd like additional components down stream to know about an issue elsewhere in the chain, you have a few options. You could use the End of Stream bit, available in bulkio port implementations, to signal to down stream components that there is no additional data. They can then use this information to clean up and shut down. You could also use messaging to send a message out to an event channel and anyone who has subscribed to this event channel can be made aware of the message. Again, it's a design decision.
I'm using ws in a Node websocket server.
In production, I frequently get this error:
Error: continuation frame cannot follow current opcode
What is causing this?
How should go about debugging and replicating this error in a development environment?
EDIT:
Doesn't seem to be specific to a browser, I've captured these errors in connections from Chrome, Firefox and IE10 and from different operating systems.
EDIT 2:
Error is thrown here. Apparently after receiving a frame with opcode 0 after a frame with a code != 1 && != 2.
EDIT 3:
RFC6455, section 5.2, shows what the opcodes mean and the frame's anatomy.
You might run Autobahn Testsuite (in fuzzing client mode) against your server. This will give you a detailed report like this (including wirelogs) of issues encountered.
Disclosure: I am original author of Autobahn and work for Tavendo.
For a continuation frame to work the frame before it needs to be a continuation frame or an initial frame of 1/text or 2/binary. So a frame that is not a continuation, text or binary frame is being sent. Or a new text or binary frame is being sent before it should.
To debug you need to analyze the code on the client side and check the frames on the sever side to figure out why it's sending frames out of order.
I started seeing this error, and it was caused by this code in my server.js:
wss.on('connection', function (client, request) {
wsg = client;
client._socket.setEncoding('utf8'); // <== oops, don't do this
// ...
}