Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Serialization] Hazelcast extension : using HazelcastSedaProducer with transferExchange=true #2101

Open
zbendhiba opened this issue Jan 4, 2021 · 9 comments
Assignees

Comments

@zbendhiba
Copy link
Contributor

zbendhiba commented Jan 4, 2021

On native mode, it's impossible use to write HazelcastSedaProducer with transferExchange=true.
The reason is there an issue while writing object of type DefaultExchangeHolder. It's related to this issue graal#460

Also for integration tests for HazelcastAggregationRepository and ReplicatedHazelcastAggregationRepository, that use the same Serializable class object.

@ppalaga ppalaga changed the title Hazelcast extension : using HazelcastSedaProducer with transferExchange=true [GraalVM 21.0.0] Hazelcast extension : using HazelcastSedaProducer with transferExchange=true Jan 4, 2021
@ppalaga
Copy link
Contributor

ppalaga commented Jan 4, 2021

Support for JDK serialization/deserialization oracle/graal#2730 was merged recently and should be delivered with GraalVM 21.0.0

@zbendhiba
Copy link
Contributor Author

I'll add the integration test when we move to GraalVm 21.0.0

@zbendhiba
Copy link
Contributor Author

zbendhiba commented Jan 6, 2021

Also add integration test for Query on Map, using a Serializable object.

@lburgazzoli
Copy link
Contributor

@davsclaus I wonder if we should start a stream to investigate a pluggable strategy for this and other similar cases i.e. allowing to use json, protobuf & what not

@davsclaus
Copy link
Contributor

The transferExchange is a bad design as it enforces to use Camel on both sides, and gives the impression that you can transfer the current state of the exchange to some cache / storage, and then retrieve it later, and then continue routing it.

Its for historical use we had it, and when Java objects wasn't yet a big big security vulnerability and warning.

Instead what is a more general concept would be to have an API for serializing / de-serializing a Camel message with its body and header (eg user payload) and not to include internal exchange state that may be stored as exchange properties and whatnot.

Such a API / contract can also be used by EIPs and components to store user payload more easily. And then we can have implementations for common types, such as you refer to with json/xml payloads. And for binary then avro/protobuf/what not

@ppalaga
Copy link
Contributor

ppalaga commented Apr 1, 2021

Blocked by quarkusio/quarkus#15380

@ppalaga ppalaga changed the title [GraalVM 21.0.0] Hazelcast extension : using HazelcastSedaProducer with transferExchange=true [Serialization] Hazelcast extension : using HazelcastSedaProducer with transferExchange=true May 26, 2021
@zbendhiba
Copy link
Contributor Author

The transferExchange is a bad design as it enforces to use Camel on both sides, and gives the impression that you can transfer the current state of the exchange to some cache / storage, and then retrieve it later, and then continue routing it.

Its for historical use we had it, and when Java objects wasn't yet a big big security vulnerability and warning.

Instead what is a more general concept would be to have an API for serializing / de-serializing a Camel message with its body and header (eg user payload) and not to include internal exchange state that may be stored as exchange properties and whatnot.

Such a API / contract can also be used by EIPs and components to store user payload more easily. And then we can have implementations for common types, such as you refer to with json/xml payloads. And for binary then avro/protobuf/what not

@davsclaus Maybe you should comment on this issue : https://issues.apache.org/jira/browse/CAMEL-16805. I'm not sure if I understood everything. Should we build something new, or should we change the transferExchange used in the HazelcastSedaProducer ?

@davsclaus
Copy link
Contributor

OK added a comment in JIRA.

@davsclaus
Copy link
Contributor

I think for now we should just NOT support transferExchange in the camel-hazelcast-extension.

Then that can be revisted later when CAMEL-16805 is implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants