We Keep Coding

Crash - Ejabberd (21

I have Ejabberd 21.01, recently upgraded, though that error/crash doesn't have any relevancy. Just wondering if there is any configuration mismatch or client is sending garbage causing this crash? Have been noticing this crash once in a while. Got following log,
2021-02-09 13:55:46.536 [error] <0.31162.0> gen_server <0.31162.0> terminated with reason: bad return value: #{tls_options => [compression_none,{dhfile,<<"/etc/ssl/ejabberd/dh.pem">>}],mgmt_max_timeout => 300000,mgmt_pending_timer => #Ref<0.3896716666.2157707268.137537>,lserver => <<"server.one.com">>,stream_version => {1,0},mgmt_stanzas_in => 1271,mgmt_id => <<138,233,247,19,252,82,167,106>>,tls_enabled => false,user => <<"11888842">>,stop_reason => {socket,closed},mgmt_max_queue => 5000,codec_options => [ignore_els],mgmt_stanzas_out => 6615,stream_id => <<"6931452676501402135">>,csi_queue => {0,...},...}
2021-02-09 13:55:46.538 [error] <0.31162.0>#p1_server:terminate:878 CRASH REPORT Process <0.31162.0> with 0 neighbours exited with reason: bad return value: #{tls_options => [compression_none,{dhfile,<<"/etc/ssl/ejabberd/dh.pem">>}],mgmt_max_timeout => 300000,mgmt_pending_timer => #Ref<0.3896716666.2157707268.137537>,lserver => <<"server.one.com">>,stream_version => {1,0},mgmt_stanzas_in => 1271,mgmt_id => <<138,233,247,19,252,82,167,106>>,tls_enabled => false,user => <<"11888842">>,stop_reason => {socket,closed},mgmt_max_queue => 5000,codec_options => [ignore_els],mgmt_stanzas_out => 6615,stream_id => <<"6931452676501402135">>,csi_queue => {0,...},...} in p1_server:terminate/7 line 878
2021-02-09 13:55:46.538 [error] <0.913.0> Supervisor ejabberd_c2s_sup had child undefined started with {ejabberd_c2s,start_link,undefined} at <0.31162.0> exit with reason bad return value: #{tls_options => [compression_none,{dhfile,<<"/etc/ssl/ejabberd/dh.pem">>}],mgmt_max_timeout => 300000,mgmt_pending_timer => #Ref<0.3896716666.2157707268.137537>,lserver => <<"server.one.com">>,stream_version => {1,0},mgmt_stanzas_in => 1271,mgmt_id => <<138,233,247,19,252,82,167,106>>,tls_enabled => false,user => <<"11888842">>,stop_reason => {socket,closed},mgmt_max_queue => 5000,codec_options => [ignore_els],mgmt_stanzas_out => 6615,stream_id => <<"6931452676501402135">>,csi_queue => {0,...},...} in context child_terminated

Looks like team has posted a new commit to fix that issue. That seems a little bug.
https://github.com/processone/ejabberd/issues/3524

How to get Wildfly server status via CLI?

I've been trying to validate if our server has started in Wildfly using the jboss-cli.bat
This is the command i'm using:
/host=slave-1/server-config=REST-server-one:read-resource(include-runtime=true)
and this is what i'm getting from the command
{
"outcome" => "success",
"result" => {
"auto-start" => true,
"cpu-affinity" => undefined,
"group" => "wildfly-server-group",
"name" => "wildfly-server",
"priority" => undefined,
"socket-binding-default-interface" => undefined,
"socket-binding-group" => undefined,
"socket-binding-port-offset" => 0,
"status" => "STARTED",
"update-auto-start-with-server-status" => false,
"interface" => undefined,
"jvm" => undefined,
"path" => undefined,
"ssl" => undefined,
"system-property" => undefined
}
Is there a command that will return the value of the status in that response?

You should be able to use the read-attribute operation.
/host=slave-1/server-config=REST-server-one:read-attribute(name=status)

I end up using this
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
String line = reader.readLine();
while (line != null) {
String[] value = line.split("=>");
if(value.length > 1){
if(value[0].contains("\"status\"")){
System.out.println(value[1]);
}
}
line = reader.readLine();
}
If anyone can suggest a better method would be greatly appreciated.

Send log4j2 stack traces over syslog

I am trying to log stack traces into Logstash.
The logging stack is ELK (ElasticSearch, Logstash, Kibana).
The application producing logs is a Java application, using slf4j as a logging interface, and log4j2 as the logging implementation.
The log4j2.xml declares this syslog Appender, with the RFC5424 format:
<Appenders>
<Syslog name="RFC5424" format="RFC5424" host="localhost" port="8514"
protocol="TCP" appName="MyApp" includeMDC="true" mdcId="mdc"
facility="LOCAL0" enterpriseNumber="18060" newLine="true"
messageId="Audit" id="App">
<LoggerFields>
<KeyValuePair key="thread" value="%t"/>
<KeyValuePair key="priority" value="%p"/>
<KeyValuePair key="category" value="%c"/>
<KeyValuePair key="exception" value="%ex{full}"/>
</LoggerFields>
</Syslog>
</Appenders>
I log a Throwable from the Java application like so:
org.slf4j.LoggerFactory.getLogger("exception_test").error("Testing errors", new RuntimeException("Exception message"));
When an exception is logged, Logstash traces something like this to show me what it persists:
{
"#timestamp":"2016-11-08T11:08:10.387Z",
"port":60397,
"#version":"1",
"host":"127.0.0.1",
"message":"<131>1 2016-11-08T11:08:10.386Z MyComputer.local MyApp - Audit [mdc#18060 category=\"exception_test\" exception=\"java.lang.RuntimeException: Exception message",
"type":"syslog",
"tags":[
"_grokparsefailure"
]
}
And I confirm that Kibana displays exactly the same JSON within the _source field of one of its log entries.
There's a problem here: no stack trace is saved. And the message, "Testing errors", is lost.
The "tags":["_grokparsefailure"] is unfortunate but not related to this question.
I tried adding <ExceptionPattern/> to see if it would change anything:
<Syslog name="RFC5424" format="RFC5424" host="localhost" port="8514"
protocol="TCP" appName="MyApp" includeMDC="true" mdcId="mdc"
facility="LOCAL0" enterpriseNumber="18060" newLine="true"
messageId="Audit" id="App">
<LoggerFields>
<KeyValuePair key="thread" value="%t"/>
<KeyValuePair key="priority" value="%p"/>
<KeyValuePair key="category" value="%c"/>
<KeyValuePair key="exception" value="%ex{full}"/>
</LoggerFields>
<ExceptionPattern>%ex{full}</ExceptionPattern>
</Syslog>
<ExceptionPattern/> replaces the log message, and also (sadly) omits all loggerFields. But it does give me a class name and line number:
{
"#timestamp":"2016-11-08T11:54:03.835Z",
"port":60397,
"#version":"1",
"host":"127.0.0.1",
"message":"at com.stackoverflow.LogTest.throw(LogTest.java:149)",
"type":"syslog",
"tags":[
"_grokparsefailure"
]
}
Again: no stack trace. And again: the message, "Testing errors", is lost.
How can I use log4j2 to log stack traces into Logstash? I don't necessarily have to use the syslog appender.
Essentially the constraints are:
Not be locked in to any particular logging infrastructure (this is why I used syslog)
Multi-line stack traces need to be understood as being a single log entry. It's undesirable for "each line of the stack trace" to be "a separate log message"
Stack traces must be able to be subjected to filters. A typical exception of mine can have a page-long stack trace. I want to filter out frames like Spring.

Log4j 2.5's SyslogAppender can only send stack traces over UDP.
<Syslog name="RFC5424" format="RFC5424" host="localhost" port="8514"
protocol="UDP" appName="MyApp" includeMDC="true" mdcId="mdc"
facility="LOCAL0" enterpriseNumber="18060" newLine="true"
messageId="LogTest" id="App">
<LoggerFields>
<KeyValuePair key="thread" value="%t"/>
<KeyValuePair key="priority" value="%p"/>
<KeyValuePair key="category" value="%c"/>
<KeyValuePair key="exception" value="%ex{full}"/>
</LoggerFields>
<ExceptionPattern>%ex{full}</ExceptionPattern>
</Syslog>
With UDP: both ExceptionPattern and LoggerFields.KeyValuePair["exception"] start working as solutions for multiline stack traces.
This is what logstash prints when I sent an exception over UDP via syslog:
{
"#timestamp" => 2016-11-14T13:23:38.304Z,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "<131>1 2016-11-14T13:23:38.302Z BirchBox.local MyApp - LogTest [mdc#18060 category=\"com.stackoverflow.Deeply\" exception=\"java.lang.RuntimeException: Exception message\n\tat com.stackoverflow.Deeply.complain(Deeply.java:10)\n\tat com.stackoverflow.Nested.complain(Nested.java:8)\n\tat com.stackoverflow.Main.main(Main.java:20)\n\" priority=\"ERROR\" thread=\"main\"] Example error\njava.lang.RuntimeException: Exception message\n\tat com.stackoverflow.Deeply.complain(Deeply.java:10)\n\tat com.stackoverflow.Nested.complain(Nested.java:8)\n\tat com.stackoverflow.Main.main(Main.java:20)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
Inside [mdc#18060 exception=\"…\"] we get the LoggerFields.KeyValuePair["exception"] stack trace.
In addition to this: the stack trace is inserted into the logged message itself, thanks to ExceptionPattern.
For reference: this is what logstash prints when I send the exception over TCP via syslog (i.e. the same SyslogAppender as described above, but with protocol="TCP" instead):
{
"#timestamp" => 2016-11-14T19:56:30.293Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "<131>1 2016-11-14T19:56:30.277Z BirchBox.local MyApp - Audit [mdc#18060 category=\"com.stackoverflow.Deeply\" exception=\"java.lang.RuntimeException: Exception message",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.296Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Deeply.complain(Deeply.java:10)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.296Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Nested.complain(Nested.java:8)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.296Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Main.main(Main.java:20)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.296Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "\" priority=\"ERROR\" thread=\"main\"] Example error",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.296Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "java.lang.RuntimeException: Exception message",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.297Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Deeply.complain(Deeply.java:10)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.298Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Nested.complain(Nested.java:8)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.298Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "at com.stackoverflow.Main.main(Main.java:20)",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
{
"#timestamp" => 2016-11-14T19:56:30.299Z,
"port" => 63179,
"#version" => "1",
"host" => "127.0.0.1",
"message" => "",
"type" => "syslog",
"tags" => [
[0] "_grokparsefailure"
]
}
It looks like TCP does actually "work", but splits the single log message into many syslog messages (for example when \n is encountered).

Log analysis to query logs based on a log message

I have a Java application that ouputs log in the format
timestamp UUID1 some information
timestamp UUID1 some more information
timestamp UUID1 x = 1
timestamp UUID2 some information
timestamp UUID2 some more information
timestamp UUID2 x = 2
timestamp UUID3 some information
timestamp UUID3 some more information
timestamp UUID3 x = 1
I want to implement a log analysis framework using Elsatic Search, LogStash and Kibana. Is it possible to get the logs only according to X value?
For example:-
If I query X = 1, I should get only the following logs.
timestamp UUID1 some information
timestamp UUID1 some more information
timestamp UUID1 x = 1
timestamp UUID3 some information
timestamp UUID3 some more information
timestamp UUID3 x = 1
If I query X = 2, I should get only the following logs.
timestamp UUID2 some information
timestamp UUID2 some more information
timestamp UUID2 x = 2
I am in control of the log message format. If it is not directly popssible to do this query, I can change the message format also.
UPDATE 1:
I will be a little more specific.
The following are my log statements.
MDC.put("uuid", UUID.randomUUID().toString());
logger.info("Assigning value to the variable : {}", name);
this.setVal(value.getVal());
logger.info("{} = {}", name, value.getVal());
logger.info("Assigned value {} to the variable : {}", value.getVal(),
name);
MDC.clear();
I received the log statements in Logstash using UDP. And I am getting the messages like.
{
"#timestamp" => "2015-04-01T10:23:37.846+05:30",
"#version" => 1,
"message" => "Assigning value to the variable : X",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-1",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "ab17b842-8348-4474-98e4-8bc2b8dd6781",
"host" => "127.0.0.1"
}
{
"#timestamp" => "2015-04-01T10:23:37.846+05:30",
"#version" => 1,
"message" => "Assigning value to the variable : Y",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-2",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "d5513e4c-de3b-4144-87e4-87b077ac8056",
"host" => "127.0.0.1"
}
{
"#timestamp" => "2015-04-01T10:23:37.862+05:30",
"#version" => 1,
"message" => "Y = 1",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-2",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "d5513e4c-de3b-4144-87e4-87b077ac8056",
"host" => "127.0.0.1"
}
{
"#timestamp" => "2015-04-01T10:23:37.863+05:30",
"#version" => 1,
"message" => "X = 1",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-1",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "ab17b842-8348-4474-98e4-8bc2b8dd6781",
"host" => "127.0.0.1"
}
{
"#timestamp" => "2015-04-01T10:23:37.863+05:30",
"#version" => 1,
"message" => "Assigned value 1 to the variable : X",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-1",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "ab17b842-8348-4474-98e4-8bc2b8dd6781",
"host" => "127.0.0.1"
}
{
"#timestamp" => "2015-04-01T10:23:37.863+05:30",
"#version" => 1,
"message" => "Assigned value 1 to the variable : Y",
"logger_name" => "com.example.logstash.Variable",
"thread_name" => "pool-1-thread-2",
"level" => "INFO",
"level_value" => 20000,
"HOSTNAME" => "pnibinkj-W7-1",
"uuid" => "d5513e4c-de3b-4144-87e4-87b077ac8056",
"host" => "127.0.0.1"
}
There are 2 UUIDs
"d5513e4c-de3b-4144-87e4-87b077ac8056" for "Y = 1"
"ab17b842-8348-4474-98e4-8bc2b8dd6781" for "X = 1"
There are two other messages for each UUID. I want to combine them into a single event.
I am not sure, how to write the multiline filter for this case.
filter {
multiline {
pattern => "."
what => "previous"
stream_identity => "%{uuid}"
}
}
"pattern" and "what" are required fields, it seems. What should I provide for these fields. How do I use Stream Identity?
Please point me in right direction.
Thanks,
Paul

You would need to combine your messages (see multiline{} filter, which supports stream_identity), and then a regular query would return the appropriate message.

this should be possible using the kibana filters if X is some unique value, but with the logs in the format shown you'd need to use the multiline filter to join the entries together.
With that in place, you could probably use a query something like
message: "X=1"

HornetQ not honoring Last Value in a Queue when Wildfly is restarted

Following is the Queue Definition I have in my standalone.xml. Queue which I am having is persistent.
<jms-queue name="CEComputeQueue">
<entry name="queue/CEComputeQueue"/>
<entry name="java:jboss/exported/jms/queue/CEComputeQueue"/>
</jms-queue>
With following Address Settings.
<address-setting match="jms.queue.CEComputeQueue">
<last-value-queue>true</last-value-queue> </address-setting>
While pushing to queue HornetQ is not retaining multiple last values as you can see the output which I have taken from the JMX Console where "_HQ_LVQ_NAME (51)" is repeated.
To reproduce this follow the steps below:
1. First I pushed a value to the queue (51) and it is not yet processed and I stop the Wildfly Server.
2. I restarted Server.
3. I pushed another value to the queue (51).
Note: Although the queue is LAST Value Queue , it still has multiple same entries shown below.
RESOLUTION ?
** How can I get it resolved, is it a Bug of HornetQ or Behaviour and
what is the possible solution to the problem.**
Output using JMX:
[standalone#localhost:9990 /] /subsystem=messaging/hornetq-server=default/jms-queue=CEComputeQueue:list-messages
{
"outcome" => "success",
"result" => [
{
"JMSMessageID" => "ID:b620436a-ce84-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360041009L,
"_HQ_LVQ_NAME" => "51",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "60fe5c1a-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426803011453L
},
{
"JMSMessageID" => "ID:c7a3aaee-ce8d-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360041166L,
"_HQ_LVQ_NAME" => "49",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "6112f59e-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426806906306L
},
{
"JMSMessageID" => "ID:4c4952f8-ce95-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360041269L,
"_HQ_LVQ_NAME" => "51",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "60fe5c1a-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426810135328L
},
{
"JMSMessageID" => "ID:2a4048fd-cea1-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360041517L,
"_HQ_LVQ_NAME" => "51",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "61105d84-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426815232187L
},
{
"JMSMessageID" => "ID:cdc0d5f8-cea5-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360041946L,
"_HQ_LVQ_NAME" => "49",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "60fe5c1a-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426817224485L
},
{
"JMSMessageID" => "ID:0e169a9e-cea7-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360042115L,
"_HQ_LVQ_NAME" => "50",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "6112f59e-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426817761918L
},
{
"JMSMessageID" => "ID:185fd030-cea7-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360042124L,
"_HQ_LVQ_NAME" => "16",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "60fe5c1a-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426817779175L
},
{
"JMSMessageID" => "ID:4c614265-cea7-11e4-a3d7-f9d18c2c2348",
"JMSExpiration" => 0,
"messageID" => 34360042157L,
"_HQ_LVQ_NAME" => "51",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "6112f59e-ce52-11e4-a3d7-f9d18c2c2348",
"JMSPriority" => 4,
"JMSTimestamp" => 1426817866426L
},
{
"JMSMessageID" => "ID:5b14c783-cead-11e4-92c2-e36be9318636",
"JMSExpiration" => 0,
"messageID" => 36507524460L,
"_HQ_LVQ_NAME" => "49",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "a3519e4e-cea8-11e4-92c2-e36be9318636",
"JMSPriority" => 4,
"JMSTimestamp" => 1426820468071L
},
{
"JMSMessageID" => "ID:5e94c684-cead-11e4-92c2-e36be9318636",
"JMSExpiration" => 0,
"messageID" => 36507524462L,
"_HQ_LVQ_NAME" => "51",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "a3519e4e-cea8-11e4-92c2-e36be9318636",
"JMSPriority" => 4,
"JMSTimestamp" => 1426820473943L
},
{
"JMSMessageID" => "ID:a5bed858-cea9-11e4-92c2-e36be9318636",
"JMSExpiration" => 0,
"messageID" => 36507523986L,
"_HQ_LVQ_NAME" => "50",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "a3519e4e-cea8-11e4-92c2-e36be9318636",
"JMSPriority" => 4,
"JMSTimestamp" => 1426818875350L
},
{
"JMSMessageID" => "ID:20a629be-ceaa-11e4-92c2-e36be9318636",
"JMSExpiration" => 0,
"messageID" => 36507524057L,
"_HQ_LVQ_NAME" => "16",
"address" => "jms.queue.CEComputeQueue",
"JMSDeliveryMode" => "PERSISTENT",
"__HQ_CID" => "a3519e4e-cea8-11e4-92c2-e36be9318636",
"JMSPriority" => 4,
"JMSTimestamp" => 1426819081548L
}
]
}

This is a bug , raised it in Wildfy Jira.
Here is the link.
https://issues.jboss.org/browse/WFLY-4479