Hazelcast custom serializer

[Maciej Żerkowski]

How to define your own Hazelcast data serializer? I have been trying with the below but without success. Maybe I do it in the wrong place and it is being override somewhere later on by Vert.x cluster setup (guessing here)?

HazelcastInstance instance = Hazelcast.getHazelcastInstanceByName("_hzInstance_1_dev");
instance.getConfig().getSerializationConfig().getSerializerConfigs().add(
            new SerializerConfig().
                setTypeClass(LoginInfo.class).
                setImplementation(new LoginInfoSerializer()));

[Jordan Halterman]

Have you tried asking on the Hazelcast forum? What is it that you're trying to accomplish? 

This is not intended to be used by the event bus (I hope), right? I have to ask since there's often a lot of confusion about how Hazelcast is used in Vert.x.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Maciej Żerkowski]

No I haven't. I wanted to start here.
Since currently data can only be shared between verticles in the same vert.x instance I need to share some data across cluster nodes somehow. So, I've picked Hazelcast for that purpose.

[Jordan Halterman]

Fair enough. I think the code looks right from what I know of Hazelcast. You can also try adding it via the XML configuration in cluster.xml if that's not working.

[Maciej Żerkowski]

I have cluster.xml from vert.x instance as a template but it hasn't got any serialisation related section. Do you know how to put that information into this file?

[Maciej Żerkowski]

I have tried:

    <serialization>
        <portable-version>0</portable-version>
        <serializers>
             <type-serializer type-class="name.of.class.to.be.serialized">name.of.serializer.class</type-serializer>
        </serializers>
    </serialization>

as in http://hazelcast.com/schema/config/hazelcast-config-3.2.xsd
but it does not seem to be working...:(
Did anyone tried this?

[Fabio Marinelli]

I think that if you intend to use shared data then your data  should implement ClusterSerializable interface (it's vert.x).

Bye

Fabio Marinelli
Software developer
LinkedIn: http://www.linkedin.com/in/fmarinelli
Twitter @fmarinelli

[Jordan Halterman]

Here's what I know:

I haven't seen anyone with this issue on this forum. But I do know that cluster.xml is basically just a Hazelcast configuration (when using the default Hazelcast cluster manager). And looking at the same docs you references above, it looks like you're on the right track. However, you'll have to make sure that the referenced class is on your Vert.x classpath when Vert.x creates the cluster manager and make sure you're actually getting the correct Vert.x Hazelcast instance from Hazelcast.

As I always say to people with Hazelcast questions, Hazelcast is an implementation detail of Vert.x, but the Vert.x 2 API does have limitations as you mentioned (which are, btw, resolved in Vert.x 3) and some users will need to use it.

Aside from what I've mentioned, hopefully someone with more experience with HZ will come along to help, or you can query the HZ forum. I have used the Vert.x Hazelcast instance before in Vertigo (http://github.com/kuujo/vertigo) but only went as far as locating and using the Vert.x Hazelcast instance, not configuring it.

Sent from my iPhone

[Jordan Halterman]

That is a Vert.x 3 interface.

Sent from my iPhone

[Maciej Żerkowski]

I have used wrong xml for this xsd - correct one is like below (small change in serializer tag):

    <serialization>
        <portable-version>0</portable-version>
        <serializers>

           <serializer type-class="com.yourCompany.vertx.LoginInfo">com.yourCompany.vertx.serializer.LoginInfoSerializer</serializer>
        </serializers>
    </serialization>

And you need to remember: Caused by: java.lang.IllegalArgumentException: Type id must be positive! Current: 0, Serializer:...

So in LoginInfoSerializer getTypeId() need to return positive value:

@Override
    public int getTypeId() {
        return 1;
    }

BTW: it there a way to instead on cp put these classes inside vert.x fat jar and instruct about that fact Hazelcast somehow?

[Jordan Halterman]

Awesome. Thanks for the update.

I'm not sure on the last question. What I've done in the past is simply put them in the Vert.x /lib directory. I'm not sure, though, if there's a more "correct" way to accomplish this given that it needs to be on the classpath when Vert.x starts.

[Maciej Żerkowski]

Yeah but in case of fat jar you do not want to use vert.x instance - all you need you have in your fat jar. Anyway, I forgot that for such use cases we have platform_lib folder - I put it there and it works fine.

Thanks for your help!

[dgo...@squaredfinancial.com]

On Sunday, 30 November 2014 00:22:50 UTC, Jordan Halterman (kuujo) wrote:

As I always say to people with Hazelcast questions, Hazelcast is an implementation detail of Vert.x, but the Vert.x 2 API does have limitations as you mentioned (which are, btw, resolved in Vert.x 3) and some users will need to use it.

Aside from what I've mentioned, hopefully someone with more experience with HZ will come along to help, or you can query the HZ forum. I have used the Vert.x Hazelcast instance before in Vertigo (http://github.com/kuujo/vertigo) but only went as far as locating and using the Vert.x Hazelcast instance, not configuring it.

And we did the same...  But I do note lately hazelcast 3, including the one recent vertx 2.1.x is compiled against, allows use of multiple hazelcast instances in one jvm, so it may be less naughty  to make your own hazelcast instance with its own config rather than trying to "borrow" vert.x's hazelcast instance.   This means two hz configs and essentially two hazelcast clusters where your nodes just happen to participate in both, so it's admittedly more complex and weird in some ways.   But there's no longer a potential for conflict between vertx's requirements and your own possibly different hazelcast config requirements, and of course no more dependency on formally undocumented vertx 2 internals.

(This wasn't possible with hazelcast 2.x used at vertx 2.1RCx time when you were doing vertigo 0.x nearer the start of the year, IIRC)

And of course it may still be best to wrap this independent hazelcast instance in a vertx-style async api for use from non-worker verticles ("don't block the event loop") and/or if you try to use hazelcast async stuff, remember that you need to vertx runoncontext or it'll be on some random hz thread)

Of course vertx 3 provides a friendly wrapper api using its hazelcast underneath for most things you might want, without any of these shenanigans,  the above are considerations primarily for vertx 2, though I can imagine places where vertx devs wouldn't want to expose some advanced/odd hazelcast feature as part of the deliberately simple (and notionally multi-backend even if hz and local-only are the only cases right now) vertx clustered shared data api in which case the separate hazelcast instance approach may still be relevant.

Just something like the below is sufficient to cause hazelcast to hand you a second instance configured from the default hazelcast.xml (overridable with a system property), distinct from vertx's (since vertx itself overrides to use cluster.xml).

static HazelcastInstance getHazelcastInstance(String instanceName) {
        Config cfg = new XmlConfigBuilder().build();
        if (instanceName != null) {
            cfg.setInstanceName(instanceName);
        }
        return Hazelcast.newHazelcastInstance(cfg);
    }
}