Hey Justin,
Just wanted to drop a quick note to say thanks for the detailed answer you gave
us. It really helped shed some light on the issue we're dealing with.
We're considering your suggestions and are thinking about trying out some other
message types besides ObjectMessage. But if we're stuck using ObjectMessage, we
might have a workaround to skip the serialization/deserialization process using
a simple transformer.
We whipped up a custom transformer class called "NoSerializationTransformer"
that implements the Transformer interface. Here's what the code looks like:
public class NoSerializationTransformer implements Transformer {
@Override
public Message transform(Message message) {
return message;
}
}
Do you know if it's possible to set this custom transformer for the Artemis
subsystem of Wildfly? We checked the docs but couldn't find the info we needed.
Not sure if this transformer approach is even doable, or if this code snippet
would be enough. Any advice on what we should do next?
Thanks again for your time and expertise, Justin. Looking forward to hearing
back from you.
Cheers,
Walter
________________________________
From: Justin Bertram <jbert...@apache.org>
Sent: Saturday, March 18, 2023 2:49:33 AM
To: users@activemq.apache.org <users@activemq.apache.org>
Subject: Re: wildfly 26.1.2 support
[You don't often get email from jbert...@apache.org. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See http://nok.it/ext for additional information.
As far as I'm aware there is no optimization to avoid serialization for
ObjectMessage instances even within the same JVM. I think such an
optimization is theoretically feasible, but it would not be
straightforward, and it would be optimizing a use-case that's well-known
for bad performance. In short, if you want good performance don't use
ObjectMessage.
The "Performance Tuning" chapter in the ActiveMQ Artemis documentation [1]
states:
Avoid ObjectMessage. ObjectMessage is convenient but it comes at a
cost. The body of a
ObjectMessage uses Java serialization to serialize it to bytes. The
Java serialized form of
even small objects is very verbose so takes up a lot of space on the
wire, also Java
serialization is slow compared to custom marshalling techniques. Only
use ObjectMessage
if you really can't use one of the other message types, i.e. if you
really don't know the type
of the payload until run-time.
There is even a comment on the ActiveMQ Artemis implementation of
ObjectMessage (i.e.
org.apache.activemq.artemis.jms.client.ActiveMQObjectMessage) [2]:
/**
* ActiveMQ Artemis implementation of a JMS ObjectMessage.
* <br>
* Don't used ObjectMessage if you want good performance!
* <p>
* Serialization is slooooow!
*/
I have personally warned folks away from ObjectMessage many times on Stack
Overflow not just because of the performance issues, but because of
security issues as well.
In short, don't use ObjectMessage if at all possible.
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/latest/perf-tuning.html#tuning-jms
[2]
https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQObjectMessage.java#L33
On Fri, Mar 17, 2023 at 5:52 PM Walter Krix (Nokia) <walter.k...@nokia.com>
wrote:
> Dear ActiveMQ Artemis Developers,
>
>
> I am writing to inquire about the configuration of the ActiveMQ Artemis
> subsystem in Wildfly 26.1.2, with regards to serialization and
> deserialization of complex Java objects.
>
>
> Currently, when using Artemis on Wildfly and sending complex Java objects,
> the message is automatically serialized. However, I would like to disable
> this feature if possible, as I believe it should not be necessary since
> both Artemis and Wildfly are running within the same JVM.
>
>
> I would greatly appreciate it if you could provide me with information on
> how to achieve this configuration. Any guidance, documentation or resources
> you can offer to assist me in this matter would be most helpful.
>
>
> Thank you for your time and attention to this matter. I look forward to
> hearing back from you soon.
>
>
> Sincerely,
>
> Walter Krix
>
>
>
