I tried official schema-registry-confluent example (consumer/producer) with my local installed confluent 4.0.0, it can send "sensor" avro message when send post request and receive in listener, but when I use kafka-avro-console-consumer tool shipped with confluent 4.0.0 to view avro message sent, the tool raised the following error (a). I also tried to consume avro message sent by kafka-avro-console-producer tool (and the message can be shown correctly in kafka-avro-console-consumer tool) , it reported the following error (b). Doesn't the given example support confluent 4.0.0? Many thanks!
(a) kafka-avro-console-consumer error =>
ERROR Unknown error when running consumer: (kafka.tools.ConsoleConsumer$:107)
org.apache.kafka.common.errors.SerializationException: Error deserializing Avro message for id -1
Caused by: org.apache.kafka.common.errors.SerializationException: Unknown magic byte!
(b) listener error =>
org.springframework.messaging.converter.MessageConversionException: Could not read JSON: Invalid UTF-32 character 0x51473863 (above 0x0010ffff) at char #1, byte #7); nested exception is java.io.CharConversionException: Invalid UTF-32 character 0x51473863 (above 0x0010ffff) at char #1, byte #7)
at org.springframework.messaging.converter.MappingJackson2MessageConverter.convertFromInternal(MappingJackson2MessageConverter.java:234) ~[spring-messaging-5.1.0.BUILD-SNAPSHOT.jar!/:5.1.0.BUILD-SNAPSHOT]
Every time there is a MessageConversionException it simply means that the provided Message Converters could not convert Message. . . and rightfully so as we can't handle every scenario, only the common ones.
So, you should implement custom Message Converter (either from scratch or extending one of the existing ones).
Here is more info on how to define custom Message Converter
https://docs.spring.io/spring-cloud-stream/docs/Fishtown.M1/reference/htmlsingle/#spring-cloud-stream-overview-user-defined-message-converters
Related
the request body is something like:
type_61e753468ecb3800497311bd_19gqMPJ3Os1,ct_name=ct_type_19gqMPJ3Oso_19gBnvupzB6,deviceId=19gBnvupzB6 La$f=257.65,Timestamp$f=1650607683.76,assetId=L"nx_devzy001_inst02",calculate_time=1650607683880i,cloud_time=1650607683781i,create_time=1650607683762i,metricsType=0i,write_time=1650610367037i,bool_test$b=true,duration$i=10i,int_test$i=-46i,la$f=78.0,lb$f=78.0,lc$f=29.0,number_test$f=-46.0,string_test$s=L"Hello你好！",times_int_val$i=1650607683762i,workstatus$i=1i 1650607683762
I got the error is "internal error" and "[0x362] Table does not exist"
Environment (please complete the following information):
TDengine Version ：2.4.0.16
In your line protocol there's (currently treated as) duplicat column name La and la, use a different name la2 will fix the problem by now.
You can also look up to the bugfix of the problem then.
I'm trying to provide a good experience to users that are using JSON and the parser is on the backend (Ruby).
Most of the time, when you get a badly formatted JSON payload the error is of the format XXX unexpected token at '<entire payload here>'. That's not very user-friendly nor practical.
My question is: Is there a list of the XXX error codes that could help create better error messages that could be understood by beginners and not-really-tech-people?
Thanks!
XXX in this kind of errors is not a special code of the error. It is just a line number from the file where this error was raised. For example, for Ruby 2.5.1 you'll get JSON::ParserError (765: unexpected token at https://github.com/ruby/ruby/blob/v2_5_1/ext/json/parser/parser.rl#L765
You can find a list in the documentation for the module.
Think this covers it:
JSON::JSONError
JSON::GeneratorError
JSON::GenericObject
# The base exception for JSON errors.
JSON::MissingUnicodeSupport
# This exception is raised if the required unicode support is missing on the system. Usually this means that the iconv library is not installed.
JSON::NestingError
# This exception is raised if the nesting of parsed data structures is too deep.
JSON::ParserError
# This exception is raised if a parser error occurs.
JSON::UnparserError
# This exception is raised if a generator or unparser error occurs.
JSON::JSONError is the parent class, so you can rescue from that and provide per-error-class messages as needed.
I feel it's worth noting that in my experience the vast majority of errors relating to JSON are of the class JSON::ParserError. Another common issue worth considering is getting ArgumentError if nil is passed as an argument.
As an example of how this could be used, you could work with something like the following:
begin
JSON.parse(your_json)
rescue JSON::JSONError, ArgumentError => e
{ error: I18n.t(e.to_s) } # <- or whatever you want to do per error
end
Hope that helps - let me know how you get on :)
I got a HL7 message with NTE segment. The HL7 message type RDE_O11 and version 2.5. While passing message with NTE, NHAPI is not parsing it. So with the following message,
MSH|^~\&|xxxx|xxxx|||||RDE^O11^RDE_O11||P|2.5||||||ASCII|||
PID||||||||||||N|||||||||
PV1|||||||||
ORC|||||||
RXO||||||||||||||||||||||||||
RXR||||||
RXE|||||M
NTE|1||#2 from 10/19/15 amb|RE
TQ1||
TQ1|||PO Q6H PRN|A||
RXR||||||
If I change the position of NTE right after MSH, NHAPI is able to parse it.
MSH|^~\&|xxxx|xxxx|||||RDE^O11^RDE_O11||P|2.5||||||ASCII|||
NTE|1||#2 from 10/19/15 amb|RE
PID||||||||||||N|||||||||
PV1|||||||||
ORC|||||||
RXO||||||||||||||||||||||||||
RXR||||||
RXE|||||M
TQ1||
TQ1|||PO Q6H PRN|A||
RXR||||||
What kind of error are you getting? The HL7 specification for the RDE_O11 message structure does allow NTE segments to appear after RXE (among several other locations). So it ought to work.
Quickfixj is rejecting the following logon message:
8=FIXT.1.1|9=163|35=A|34=77086|1128=9|49=XXxVENUExXX|56=XXxUSxXX|52=20140704-11:24:22.308|108=4|98=0|1137=9|789=78069|58=RFA:f718fdb8-2ed3-4e0b-965f-4305188d06f9|1409=0|1407=100|10=013|
The actual log entry for it is:
20140704-11:24:22.316 ERROR [QFJ Message Processor] quickfixj.errorEvent - FIXT.1.1:XXxUSxXX->XXxVENUExXX: Rejecting invalid message: quickfix.FieldException: Tag appears more than once, field=1407: 8=FIXT.1.1^A9=184^A35=A^A34=77086^A49=XXxVENUExXX^A52=20140704-11:24:22.308^A56=XXxUSxXX^A1128=9^A58=RFA:f718fdb8-2ed3-4e0b-965f-4305188d06f9^A98=0^A108=4^A553=USRC^A554=test234^A789=7806 9^A1137=9^A1407=100^A1409=0^A10=093^A
Tag 1407 doesn't appear more than once though. We're using Quickfixj 1.5.3. With a FIX Version 5.0 SP2 - EP100 data dictionary. I can't see any issues with the data dictionary entries. The Logon message fields are all flat (except for the optional MsgTypeGrp which is not being used). Have tried with ValidateFieldsOutOfOrder as both Y and N. Config entries are:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=4
FileStorePath=/dir/storeLoc
FileLogPath=/dir/logLoc
StartDay=sun
StartTime=09:55:00
EndDay=sun
EndTime=09:45:00
UseDataDictionary=Y
AppDataDictionary=/dir/dicLoc/QuickFIX_EP100.xml
TransportDataDictionary=/dir/dicLoc/QuickFIX_EP100.xml
ValidateFieldsOutOfOrder=N
EnableNextExpectedMsgSeqNum=Y
# Only the SP2 version supported
DefaultApplVerID=9
DefaultApplExtID=100
BeginString=FIXT.1.1
TargetCompID=XXxVENUExXX
TargetSubID=XXxSUBxXX
# Endpoint
SocketConnectHost=xxx.xxx.xxx.xxx
SocketConnectPort=XXXXX
[SESSION]
SenderCompID=XXxUSxXX
SenderLocationID=XXxLocxXX
Anyone have any ideas what could cause this. It couldn't be because there is '1407' in today's date?
I am new to telecom domain
I am trying to encode and decode the ranap errorIndication message.
but the specification specifies that
Procedure Code is to be used
if Criticality Diagnostics is part
of Error Indication procedure,
and not within the response
message of the same
procedure that caused the
error.
So if I include the procedure code of the failing message in the errorIndication message.Then the wireshark shows the errorIndication as the SACK of the failed message.
So I want to know how we can include the procedure code of the failing message in the errorIndication so that Wireshark should treat the message correctly.
Thanks in Advance.
A quick look at 3GPP TS 25.413 (RANAP signalling) shows that Criticality Diagnostics (9.2.1.35) is part of the Error Indication message (9.1.41).
In section 8.27, the spec says
The Error Indication procedure is initiated by a node to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.
The definition for Procedure Code that you quoted in the question, makes it clear that the Procedure Code refers to a message that is NOT being replied to with the Error Indication.
In the Error Indication (section 9.1.41), there is also no code that refers to the message that caused the Error Indication.
The Error Indication information elements are
Message Type
Cause
Criticality Diagnostics (includes the Procedure Code that is causing the error)
CN Domain indicator
Global RNC ID
Global CN ID
Extended RNC ID
So, my conclusion, based on your description, is that I think Wireshark may have interpreted the spec wrongly. Wireshark seems to be looking for a message to which the Error Indicator is a reply.
But the Procedure Code is only supposed to tell you which message caused the error and should be re-sent. It's not supposed to tell you that the Error Indicator is a reply to that particular message.
Apologies if I am slandering Wireshark - if anyone comes up with an answer that proves me wrong, I will happily delete this post. Maybe you should ask this question on the Wireshark forum. I couldn't see anything like the issue you describe among the questions there.