Vert.x 3.x Where is the Shared Data Set types?

[bytor99999]

In upgrading our code, we have couple of places that is using a SharedData Set. And the creation of that Set occurs if the Set didn't occur before.

However, in trying to fix that code to work with Vert.x 3.x I find it a bit more difficult to convert. As I don't see a getLocalSet or such, so only localMap, which then if you were to say well put the Set as the value to a key in the map, then how would that Set get automatically created for us, like it did with shared Sets in Vert.x 2.x

Thanks

Mark

[Nimrod Ticozner]

We are currently experiencing the same issue and instead of duplicating the same question I join yours in hope of a solution.

Thanks, 

Nimrod.

[Tim Fox]

Could you reframe the issue? I'm not sure I have parsed it correctly.

--
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.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0e086369-af29-404c-99bb-d0d0aba4638b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nimrod Ticozner]

Sure, We are in the process of upgrading our code to vertx 3.0. I came across a great post in vertx.io blog (http://vertx.io/blog/checklist-for-migrating-from-vert-x-2-1-x-to-vert-x-3-part-one/) which describes the process of upgrading to vertx 3.0 . In this post there is a section which talks about shared data, Quote : 

  "SharedData no longer has shared sets. It has a Map of SharedData, so an entry in that Map of shared data could be the name of the set as the key, and a Set as the value. It actually gives         you more flexibility of what you put into Shared data, so this is actually a big win for us."

Following this guideline we refactored our code likewise : 

   LocalMap<String, Set<String>> showsMessages = vertx.sharedData().getLocalMap("showsMessages");

   showsMessages.putIfAbsent(showId, new HashSet<String>());

   Set<String> specificShowMessages = showsMessages.get(showId);

and got the following exception : 

java.lang.IllegalArgumentException: Invalid type for shareddata data structure: java.util.concurrent.HashSet

at io.vertx.core.shareddata.impl.Checker.checkType(Checker.java:45)

at io.vertx.core.shareddata.impl.LocalMapImpl.putIfAbsent(LocalMapImpl.java:80)

at com.vp.vertx.cluster.handler.managment.PublishEventBusHandler.updateShowMessages(PublishEventBusHandler.java:72)

at com.vp.vertx.cluster.handler.managment.PublishEventBusHandler.handle(PublishEventBusHandler.java:51)

at com.vp.vertx.cluster.handler.managment.PublishEventBusHandler.handle(PublishEventBusHandler.java:23)

at io.vertx.core.eventbus.impl.EventBusImpl$HandlerRegistration.handle(EventBusImpl.java:1108)

at io.vertx.core.eventbus.impl.EventBusImpl.lambda$doReceive$189(EventBusImpl.java:755)

at io.vertx.core.eventbus.impl.EventBusImpl$$Lambda$48/312707322.handle(Unknown Source)

at io.vertx.core.impl.ContextImpl.lambda$wrapTask$15(ContextImpl.java:314)

at io.vertx.core.impl.ContextImpl$$Lambda$12/1724924833.run(Unknown Source)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)

at java.lang.Thread.run(Thread.java:745)

Thanks, 

Nimrod.

[Assen Todorov]

This part of the blog post you have referred to, seems to be wrong. According to the JavaDoc of SharedData, it is not allowed to share Set. You could implement some kind of ShareableSet by implementing Shareable but your implementation must be immutable.

http://vertx.io/vertx2/api/java/org/vertx/java/core/shareddata/SharedData.html

Regards,

Assen

[Assen Todorov]

Hi,

Sorry, I just noticed, that I have referred to the Vert.x 2 JavaDoc in my previous post.
I must admit, that I am quite suprised that the data type limitations for sharing data in Vertx 3 are nowhere documented. Digging into the code of LocalMap shows clearly that the same limitations, described in the old documentation still apply for Vertx 3 (plus JsonObject and JsonArray).
Maybe some Insider could explain us, why they are not documented.

Regards,

Assen

[Clement Escoffier]

Hi,

Values of local maps cannot be a set (or a list), because it needs to be “explicitly” stated as thread safe. To do so, create a class implementing “Shareable” (it’s a marker interface). However be sure that these class is thread safe.

For a list, you can use something like:

public class Messages extends CopyOnWriteArrayList<String> implements Shareable {

}

There are also a CopyOfWriteArraySet for sets.

Clement

--
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.
Visit this group at http://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/a720c162-38f5-4358-a7b6-60137f734af1%40googlegroups.com.

[Nimrod Ticozner]

Hi, 

Thank you all for your replies.

@Clement I'll try your solution.

Thanks, 

Nimrod.

[Tim Fox]

On 19/08/15 11:38, Nimrod Ticozner wrote:

Sure, We are in the process of upgrading our code to vertx 3.0. I came across a great post in vertx.io blog (http://vertx.io/blog/checklist-for-migrating-from-vert-x-2-1-x-to-vert-x-3-part-one/) which describes the process of upgrading to vertx 3.0 . In this post there is a section which talks about shared data, Quote : 

  "SharedData no longer has shared sets. It has a Map of SharedData, so an entry in that Map of shared data could be the name of the set as the key, and a Set as the value.

This is not really true unless you wrap the Set in your own class and mark it as Shareable. But I wouldn't recommend that as you're opening yourself up to all sorts of race conditions.

If you want shared sets you can just use getLocalMap() and treat it as a set (i.e. just use a constant value for the values) - this is how it worked internally in Vert.x 2 anyway.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0c05f0bb-6df8-4570-8747-e6d4dcf86b35%40googlegroups.com.

[Tim Fox]

On 20/08/15 07:18, Assen Todorov wrote:
> Hi,
>
> Sorry, I just noticed, that I have referred to the Vert.x 2 JavaDoc in my previous post.
> I must admit, that I am quite suprised that the data type limitations for sharing data in Vertx 3 are nowhere documented.

http://vertx.io/docs/vertx-core/java/#_using_shared_data_with_vert_x

"Local shared maps only allow certain data types to be used as keys and
values. Those types must either be immutable, or certain other types
that can be copied like Buffer. In the latter case the key/value will be
copied before putting it in the map."

https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/shareddata/impl/Checker.java#L29

[Tim Fox]

Shareable is an undocumented feature - I wouldn't recommend using it.

Even if you use a thread safe list/set you won't get the checks that the objects that you add to the set are thread safe --> race conditions.

This is exactly the situation that Shared Data was supposed to protect you against.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/43cbd8d7-b91d-4882-9d65-478465d54ab0%40googlegroups.com.

[Nimrod Ticozner]

"Even if you use a thread safe list/set you won't get the checks that the objects that you add to the set are thread safe --> race conditions.

This is exactly the situation that Shared Data was supposed to protect you against."

If i use a thread safe set and the objects that i add to the set are immutable you still don't recommend this approach ?

Thanks, 

Nimrod.

[Tim Fox]

On 20/08/15 10:38, Nimrod Ticozner wrote:

"Even if you use a thread safe list/set you won't get the checks that the objects that you add to the set are thread safe --> race conditions.

This is exactly the situation that Shared Data was supposed to protect you against."

If i use a thread safe set and the objects that i add to the set are immutable you still don't recommend this approach ?

Even though you have the best of intentions, you can bet that someone will forget and add a non thread-safe object, or they add an object that they think is thread-safe and is not, and I'll be debugging the reported race condition on this google group in a few months time ;)

I'm not sure why you don't just use LocalMap? This has the checks built in for you.

You can treat the map like a set.

e.g. set.add(foo) can be implemented as map.put(foo, SOME_CONSTANT_OBJECT)
set.contains(foo) => map.containsKey(foo)

In fact this is how shared sets are implemented in Vert.x 2 anyway ;)

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2e5f9888-0d54-4365-949f-566efb8b0f92%40googlegroups.com.