Slack digest for #general - 2018-06-24

[Apache Pulsar Slack <ap...@gmail.com>]

2018-06-23 11:23:01 UTC - Nicolas Ha: what happened to `org.apache.pulsar.common.configuration PulsarConfigurationLoader/isComplete` in 2.0? Is there something equivalent now to validate the config?
----
2018-06-23 11:25:27 UTC - Nicolas Ha: and more importantly `org.apache.pulsar.common.util.FieldParser`? Can someone point me to the new way of generating config/starting a pulsar broker?
----
2018-06-23 11:27:04 UTC - Nicolas Ha: Or is it too soon to play with the v2?
----
2018-06-23 11:41:35 UTC - Sijie Guo: @Nicolas Ha I don’t think those classes were changed for v2. 

2.0.0 has a released a month ago, 2.0.1 is released a few days ago, and 2.1.0 is coming next week. so it is not “too soon” to play. it is moving fast
----
2018-06-23 11:42:41 UTC - Nicolas Ha: Moving fast indeed! Good to know :smile:  I will double check my changes, thanks
+1 : Sijie Guo
----
2018-06-23 12:04:44 UTC - Nicolas Ha: For some reason I had to add`org.apache.pulsar.common/`2.0.0-rc1-incubating` and `org.apache.pulsar/pulsar-broker-common "2.0.0-rc1-incubating"` to my dependencies
----
2018-06-23 12:49:39 UTC - Sijie Guo: what dependencies you used to use?
----
2018-06-23 13:47:10 UTC - Nicolas Ha: So when I update `org.apache.pulsar/pulsar-client` and `org.apache.pulsar/pulsar-broker-shaded` (the only ones I used to use) from `1.21.0-incubating` to `2.0.0-rc1-incubating`
- (1) It complains about `java.lang.ClassNotFoundException: com.ea.agentloader.AgentLoader` - I don’t really use it so I remove the reference to it
- (2) It then complains about `java.lang.ClassNotFoundException: org.apache.pulsar.common.configuration.PulsarConfigurationLoader` - I add `org.apache.pulsar.common/`2.0.0-rc1-incubating` and `org.apache.pulsar/pulsar-broker-common "2.0.0-rc1-incubating"` to my dependencies
- (3) however at runtime I now get ```[org.apache.pulsar.shade.org.jvnet.hk2.logger:108] - Cannot find a default implementation of the HK2 ServiceLocatorGenerator```
----
2018-06-23 13:47:59 UTC - Nicolas Ha: the code looks like it is there in github, maybe the dependencies or packaging changed?
----
2018-06-23 13:51:09 UTC - Nicolas Ha: could it be because some dependencies changed versions and now conflict with the ones I have?
----
2018-06-23 17:07:14 UTC - Boris Gordeev: @Boris Gordeev has joined the channel
----
2018-06-23 23:56:14 UTC - Boris Gordeev: Good day.
I'm trying to find a solution for issue #2009 since we could really use that in production.
Could you please help me with figuring out how non-persistent topics are being replicated? E.g. if I have created a non-persistent topic in one broker instance by writing into it from a client, is it going to get automatically replicated to other broker instances? If so, does it mean that collections from "multiLayerTopicsMap" properties in BrokerServices across different brokers set to work in a cluster are eventually going to have information about all common non-persistent topics?
----
2018-06-24 00:02:03 UTC - Matteo Merli: Data for non-persistent topic is not replicated across multiple brokers. There is the option for geo-replication across multiple clusters. If you need to make sure data is not lost, you should use the regular persistent topics
----
2018-06-24 00:12:47 UTC - Boris Gordeev: Oh, I see. That was quick, thank you!
----