Why is the SLAB service warning of dropped events for my ETW event source? - trace

I'm getting this error on one of my servers:
EventId : 806, Level : Warning, Message : Some events will be lost because of bu
ffer overruns or schema synchronization delays in trace session: Microsoft-Seman
ticLogging-Etw-Mobile2ConsoleListener., Payload : [sessionName : Microsoft-Seman
ticLogging-Etw-Mobile2ConsoleListener] , EventName : TraceEventServiceEventsWill
BeLostInfo, Timestamp : 2014-02-28T10:38:46.6527952Z
I have another server which I think is set up identically. However, when I run the ETW SLAB service to listen for ETW events emitting from my event source I get the above warning but not on the other server. What would cause this?

I've seen this error when I pass a null value for a string payload ... see my other question on etw ...

Related

How does the Camel Netty TCP socket consumer decide how to split incoming data into messages (and is it configurable)?

I'm working with a Camel flow that uses a Netty TCP socket consumer to receive messages from a client program (which is outside of my control). The client should be opening a socket, sending us one message, then closing the socket, but we've been seeing cases where instead of one message Camel is "splitting" the text stream into two parts and trying to process them separately.
So I'm trying to figure out, since you can re-use the same socket for multiple Camel messages, but TCP sockets don't have a built-in concept of "frames" or a standard for message delimiters, how does Camel decide that a complete message has been received and is ready to process? I haven't been able to find a documented answer to this in the Netty component docs (https://camel.apache.org/components/3.15.x/netty-component.html), although maybe I'm missing something.
From playing around with a test script, it seems like one answer is "Camel assumes a message is complete and should be processed if it goes more than 1ms without receiving any input on the socket". Is this a correct statement, and if so is this behavior documented anywhere? Is there any way to change or configure this behavior? Really what I would prefer is for Camel to wait for an ETX character (or a much longer timeout) before processing a message, is that possible to set up?
Here's my test setup:
Camel flow:
from("netty:tcp://localhost:3003")
.log("Received: ${body}");
Python snippet:
DELAY_MS = 3
def send_msg(sock, msg):
print("Sending message: <{}>".format(msg))
if not sock.sendall(msg.encode()) is None:
print("Message failed to send")
time.sleep(DELAY_MS / 1000.0)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
print("Using DELAY_MS: {}".format(str(DELAY_MS)))
s.connect((args.hostname, args.port))
cutoff = int(math.floor(len(args.msg) / 2))
msg1 = args.msg[:cutoff]
send_msg(s, msg1)
msg2 = args.msg[cutoff:]
send_msg(s, msg2)
response = s.recv(1024)
except Exception as e:
print(e)
finally:
s.close()
I can see that with DELAY_MS=1 Camel logs one single message:
2022-02-21 16:54:40.689 INFO 19429 --- [erExecutorGroup] route1 : Received: a long string sent over the socket
But with DELAY_MS=2 it logs two separate messages:
2022-02-21 16:56:12.899 INFO 19429 --- [erExecutorGroup] route1 : Received: a long string sen
2022-02-21 16:56:12.899 INFO 19429 --- [erExecutorGroup] route1 : Received: t over the socket
After doing some more research, it seems like what I need to do is add a delimiter-based FrameDecoder to the decoders list.
Setting it up like this:
from("netty:tcp://localhost:3003?sync=true"
+ "&decoders=#frameDecoder,#stringDecoder"
+ "&encoders=#stringEncoder")
where frameDecoder is provided by
#Bean
ChannelHandlerFactory frameDecoder() {
ByteBuf[] ETX_DELIM = new ByteBuf[] { Unpooled.wrappedBuffer(new byte[] { (char)3 }) };
return ChannelHandlerFactories.newDelimiterBasedFrameDecoder(1024, ETX_DELIM,
false, "tcp");
}
seems to do the trick.
On the flip side though, it seems like this will hang indefinitely (or until lower-level TCP timeouts kick in?) if an ETX frame is not received, and I can't figure out any way to set a timeout on the decoder, so would still be eager for input if anyone knows how to do that.
I think the default "timeout" behavior I was seeing might've just been an artifact of Netty's read loop speed -- How does netty determine when a read is complete?

How stop execution and send ack/nack with error message in mirth 3.4?

I'm new in mirth so sorry if my question may seems naive.
I've a mirth channel that recives hl7 messages, and this is fine, also I've some filters and transformers both in Source and Destination.
When all is fine at the end of destination I send an ACK with a message, for this for this purpose I've made this function in code Templates:
function getAck(success, detailMessage, statusMessage) {
if (!detailMessage)
detailMessage = success ? "Operation completed successfully" : "Some error occours";
if(!statusMessage)
statusMessage = detailMessage;
if (success) {
ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AA", detailMessage);
resp = new Response(com.mirth.connect.userutil.Status.SENT, ack, statusMessage);
} else {
ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AE", detailMessage);
resp = new Response(com.mirth.connect.userutil.Status.ERROR, ack, statusMessage, detailMessage);
}
return resp;
}
So I use ACKGenerator.generateAckResponse for creating an Ack and Response for send response at client. This work but only in destination and that's my problem.
If I get an error before destination (e.g. in filters, transformer, ...) I don't be able to stop execution and send an NACK with an explaination of the error and this is what I would like to do.
Am I wrong doing things in this way?
You can store a Response in the responseMap in any filters or transformers. Once you define a key in the responseMap, it should be available as a selection in the response drop down on the source tab of your channel (instead of picking a destination.)
Your current connector should stop processing a message with an ERROR status if you manually throw an exception after setting the desired value in the responseMap. If you are in a filter, you could also filter the message instead of throwing the exception.
If you are worried about an uncaught exception, you could initialize the responseMap variable with an "Unknown Error" message at the first point in the channel where your custom code is defined that affects messages directly (likely the source filter from your description, but could possibly be the pre-processor or attachment handler if you use those.) The expectation is that this would be replaced with a more descriptive error or a success if the message makes it all the way through to the end, but the channel will always have something to return.
There are filter and transformer in the "Source" tab. If your expecting an error there or on other destinations, you could try:
Adding a try-catch code block in your filter and transformer.
Use your custom code template function in your filter and transformer to catch the error or issue.
Create a separate channel that will receive the ACK/NACK which will be responsible in forwarding that message to the client.
In your try-catch code block or custom code template, use the method router.routeMessageByChannelId to forward the ACK/NACK to the other channel (step 3).
Note: You'll need to disable the default response in your original channel since you have the other channel that'll forward the ACK/NACK. You'll also need to consider if the client's machine expects a valid ACK/NACK immediately when they sent the HL7 message, depends on their setup.

Failed to read HTTP message:ion: JSON parse error: Unexpected end-of-input in VALUE_STRING : Unexpected EOF read on the socket

When a client is sending an image to one of the rest endpoints, only part of the data is being received.
To be sure what is happening I made a trace with Wireshark and analyzed it. The application is indeed not receiving the last part of the message. This is because the application is not able to receive all the data within the 900ms timeout that is specified on the Client side. Its buffers are full halfway through the reception.
I get application warning
org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
[http-nio-0.0.0.0-9999-exec-35] Failed to read HTTP message:
org.springframework.http.converter.HttpMessageNotReadableException:
I/O error while reading input message; nested exception is
java.io.EOFException: Unexpected EOF read on the socket
And the client gets Connection timeout.
I have got a solution to my problem. I have increased the socket buffer size in my application. I have added following code to my Application class.
#Bean
public EmbeddedServletContainerFactory embeddedServletContainerFactory() {
TomcatEmbeddedServletContainerFactory tomcatEmbeddedServletContainerFactory = new TomcatEmbeddedServletContainerFactory();
tomcatEmbeddedServletContainerFactory.setProtocol("org.apache.coyote.http11.Http11Nio2Protocol");
tomcatEmbeddedServletContainerFactory.addConnectorCustomizers((TomcatConnectorCustomizer) connector -> {
connector.setProperty("socket.rxBufSize", "5000000");
});
return tomcatEmbeddedServletContainerFactory;
}

How Can I Manipulate Some/IP Message Content On Run Time?

I was trying to manipulate SOME/IP messages by falsifying their content(Payload) sent between 2 ECUs at run time.
After setting up the Hardware VN6510A MAC Bypassing and integrating it in the data traffic path between those 2 ECUs to monitor and control all Ethernet data streams.
ECU A ---> eth1 interface --VN6510A-- eth2 interface ---> ECU B
I successfully catch our target SOME/IP messages and I also succefully manipulate their paylod.
But at the end we got 2 SOME/IP messages: the real coming message and the falsified message forwarded at the same time.
How could we bound those 2 SOME/IP messages, the real message and the falsified message together, so that we could have just one falsified SOME/IP message, knowing that I am using the same SOME/IP message handle.
I used the callback function void OnEthPacket(LONG channel, LONG dir, LONG packet) to register a received Ethernet packet.
Probably by setting your VN.... to "Direct" and not "MAC Bypassing"
Well we could not manipulate Messages at run time using the vector box VN6510A Solution because simply their box doesn't support this feature.

Intercepting Bus messages in gstreamer plugin

I'm writing a gstreamer plugin that uses a uridecodebin. I'd like to be able to intercept the error that occurs when the uridecodebin is unable to open a file (either because of a malformed URI, an unknown file format, or a non-existent file) before it's reported to the application using the pipeline. When I try to add a watch to the uridecodebin's bus myself, it fails (gst_bus_create_watch: assertion bus->priv->poll != NULL) and I get a segfault.
How can I intercept the error before it's reported to the application so that I can gracefully fail internally? It isn't a critical error for the plugin as a whole if the file isn't loaded, and I'd like to be able to do some cleanup work when that happens.
You need to read this page:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-bus.html
Using wxpython, I do the following:
# Create the bus to listen for messages
bus = Gplayer.get_bus()
bus.add_signal_watch()
bus.enable_sync_message_emission()
bus.connect('message', self.OnBusMessage)
# Listen for gstreamer bus messages
def OnBusMessage(self, bus, message):
t = message.type
if t == Gst.MessageType.ERROR:
Gplayer.set_state(Gst.State.NULL)
self.OnStop(None)
wx.MessageBox('Gstreamer Error - Unsupported file type, Corrupt file,\
Unable to access or Invalid Output Device', 'Error', wx.OK | wx.ICON_INFORMATION)
Or in your case, don't report anything.
EDIT:
You can parse the message to see part 1 which will be the error and part 2 which will be a more verbose explanation.
# Listen for gstreamer bus messages
def OnBusMessage(self, bus, message):
t = message.type
if t == Gst.MessageType.ERROR:
print "Part 1",Gst.Message.parse_error (message)[0]
print "part 2",Gst.Message.parse_error (message)[1]
This is what I get from the above for a missing file:
Part 1 Not Found
part 2 gstsouphttpsrc.c(1192): gst_soup_http_src_parse_status (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Not Found (404), URL: http://localhost/vvvv.mp3
Note: This assumes that you will add code to the existing watch
Edit 2:
With regard to your second comment, have you investigated gst_bus_new().
It appears at first glance, that it may help you.