2019-03-28 09:50:42 UTC - Kirill Merkushev: @Kirill Merkushev has joined the 
channel
----
2019-03-28 10:32:03 UTC - David Tinker: Is it safe to move the Bookkeeper 
ledgers directory to a different location in a live cluster? I will shutdown 
pulsar and bookkeeper on the node first, copy ledgers to its new location, 
update ledgerDirectories in bookkeeper.conf and then start them up again. I am 
worried that full paths to stuff in ledgers might appear in Zookeeper or the 
journal or something.
thinking_face : David Tinker
----
2019-03-28 10:53:43 UTC - Shivji Kumar Jha: It seems there is a problem with 
--output option in
```bin/pulsar tokens create-secret-key --output my-secret.key```

This generates some encoded bytes on stdout:
```bin/pulsar tokens create-secret-key```

But --ouput does not generate a file at all.
----
2019-03-28 10:55:32 UTC - Shivji Kumar Jha: Doc reference: 
<https://pulsar.apache.org/docs/en/security-token-admin/#creating-a-secret-key>
----
2019-03-28 10:57:00 UTC - Alexandre DUVAL: It's generating it at the root dir 
of pulsar.
----
2019-03-28 10:57:08 UTC - Shivji Kumar Jha: let me see
----
2019-03-28 10:57:29 UTC - Alexandre DUVAL: You can define an absolute path.
----
2019-03-28 10:58:03 UTC - Shivji Kumar Jha: It is indeed there at the root 
directory of pulsar - thanks @Alexandre DUVAL
----
2019-03-28 11:50:45 UTC - Shubham Maheshwari: @Shubham Maheshwari has joined 
the channel
----
2019-03-28 11:55:03 UTC - Shubham Maheshwari: Hey Guys ..
I am using the pulsar java client lib (v2.3.0)
I am creating multiple consumers for a subscription in shared mode, but the 
messages are getting delivered to only one (and not to the rotating to the next 
idle consumer)
following is the code to create the consumers:
----
2019-03-28 11:55:25 UTC - Shubham Maheshwari: 
----
2019-03-28 11:55:34 UTC - Shubham Maheshwari: can anyone help please.
----
2019-03-28 12:03:35 UTC - Shubham Maheshwari: I tried the same with lib v2.2.0 
.. its working fine
----
2019-03-28 12:37:48 UTC - Darragh: so with more experiments to figure out where 
tail latency spikes are coming from I've noticed that  writing the journal to 2 
locations (on the same disk) instead of 1 seems to half the spikes.   This 
seems to tell me that the problem lies with the journal flushes?  Can I tune 
some parameter to do this more frequently maybe, so that the spikes are less 
outspoken (at the possible cost of a general higher normal latency) or is there 
another way to soften the spikes ?
----
2019-03-28 12:38:52 UTC - Steve Kim: 
<https://github.com/apache/pulsar/pull/3929>
+1 : jia zhai
clap : jia zhai
----
2019-03-28 14:36:26 UTC - Ezequiel Lovelle: Hi @Shubham Maheshwari please try 
to put `+ i` variable part on `subscriptionName` instead of `consumerName`
----
2019-03-28 14:37:44 UTC - Ezequiel Lovelle: please take a look at the comment 
above.
----
2019-03-28 15:51:45 UTC - Ryan Samo: Hey guys,

I have a scenario that I need some quick advice on if someone could lend their 
expertise?

If you have...

- 1 partitioned topic

- Message retention = 24 hours

- Message expiry = 24 hours

- 1 active consumer subscription

Can you...

- Create another subscription to read messages from N to N offset? Like if you 
wanted to basically replay some messages that had already been acknowledged in 
the past 24 hours but without interrupting the consumer that is already in 
place?

- I see from the admin side of Pulsar, the API has "Reset subscription to 
message position closest to absolute timestamp (in ms)." Can we use that on the 
2nd subscription to place the other consumer close enough to replay the already 
acknowledged messages?

The reader interface would be ideal but we have a partitioned topic in this 
case. Just trying to figure out if this is even possible?

Thanks!
----
2019-03-28 15:54:04 UTC - Matteo Merli: You can create a reader for each 
partition 
----
2019-03-28 15:55:09 UTC - Matteo Merli: Use `client.getPartitionsForTopic()` to 
get the list of partitions 
----
2019-03-28 15:55:35 UTC - Ryan Samo: Oh interesting!
----
2019-03-28 15:56:21 UTC - Ryan Samo: Is there a good reader example on the 
github or elsewhere that would be a good starting point?
----
2019-03-28 15:56:46 UTC - Matteo Merli: Not sure :)
----
2019-03-28 15:57:16 UTC - Matteo Merli: But you can treat each partition as a 
“non-partitioned” topic
----
2019-03-28 15:57:53 UTC - Ryan Samo: Ok perfect, sounds like a good science 
experiment on my end. Thanks @Matteo Merli 
----
2019-03-28 16:02:29 UTC - Emma Pollum: Morning guys!
Last night, our zookeeper disks ran full, and after shutting down and growing 
the disks we had full functionality, but none of our messages were in the 
system. Any ideas on how to recover them, or how to prevent this in the future?
----
2019-03-28 16:08:45 UTC - Matteo Merli: Is the ZK data recovered?
----
2019-03-28 16:09:24 UTC - Emma Pollum: It appears to be. My pulsar setup is 
producing and consuming new messages
----
2019-03-28 16:10:20 UTC - Emma Pollum: Where is topic data stored? The 
namespaces and tenant information was all solid, but no topics showed up until 
I started producing to them again
----
2019-03-28 16:11:02 UTC - Matteo Merli: That would be under 
`/managed-ledgers/...`
----
2019-03-28 16:11:54 UTC - Emma Pollum: I definitely see that my bookies data 
still has a significant number of entries, so my messages are still there, just 
not in a way zk can see?
----
2019-03-28 16:14:00 UTC - Matteo Merli: But is the topic metadata completely 
missing? Did ZK come back up with a consistent state or it was rolled back to 
an earlier snapshot ?
----
2019-03-28 16:15:05 UTC - Emma Pollum: All we did was shut down the service, 
grow the disks and remount them. No rollback.
----
2019-03-28 16:16:14 UTC - Ryan Samo: Sorry @Matteo Merli, I’m sure you’re 
questioned out by now lol... and please help @Emma Pollum 1st.

If you have a cluster of bookies, say 6 of them, and you have a write quorum of 
2, what happens if the underlying storage fills up?

Also, if you are calculating available storage to Bookkeeper, would you sum all 
of the drives together , 6 servers with 100G each = 600G available  or do we 
use 1 server x 100G = 100G Max?
----
2019-03-28 16:16:16 UTC - Matteo Merli: Uhm, then I don’t know why they would 
disappear after restart
----
2019-03-28 16:16:33 UTC - Emma Pollum: :disappointed: me either
----
2019-03-28 16:23:47 UTC - Chris DiGiovanni: @Emma Pollum did you try bouncing 
your broker(s)?
----
2019-03-28 16:25:02 UTC - Chris DiGiovanni: I had something similar happen to 
me when trying to deploy k8s.  Though it was early on in my testing and can't 
remember if that resolved it or not.
----
2019-03-28 16:29:51 UTC - Dave Southwell: Colleague of @Emma Pollum's here.  
Yes @Chris DiGiovanni we did.
----
2019-03-28 16:31:20 UTC - Chris DiGiovanni: :confused:
----
2019-03-28 16:32:01 UTC - Chris DiGiovanni: I guess the next thing I would 
start doing is digging into the bookkeeper shell cmd to see if it thinks the 
data is there or not.
----
2019-03-28 16:42:55 UTC - Emma Pollum: I was able to see that it seems our 
messages are there, but the ledgers are marked "CLOSED"
----
2019-03-28 16:42:56 UTC - Emma Pollum: ledgerID: 
00000000-0000-0000-0000-00000000c023
BookieMetadataFormatVersion     2
quorumSize: 2
ensembleSize: 2
length: 3971383
lastEntryId: 49999
state: CLOSED
segment {
  ensembleMember: "10.128.0.10:3181"
  ensembleMember: "10.128.0.185:3181"
  firstEntryId: 0
}
digestType: CRC32C
password: ""
ackQuorumSize: 2
----
2019-03-28 16:43:22 UTC - Emma Pollum: Can you help me understand what happens 
when a ledger is CLOSED?
----
2019-03-28 16:44:42 UTC - Chris DiGiovanni: ```
After the ledger has been closed---either explicitly or because the writer 
process crashed---it can then be opened only in read-only mode.
```
----
2019-03-28 16:46:47 UTC - Chris DiGiovanni: I just started digging into Pulsar 
around 3 Weeks ago.  So this is fairly new to me as well.  Does the bookkeeper 
cluster look in a healthy state.  No odd logs, bookeeper shell returns both as 
available?
----
2019-03-28 17:03:34 UTC - Emma Pollum: Yeah, now that I dig into more of the 
bookkeeper ledger meta, i have at least one ledger that has a different 
ensemble size and quorum size.
Also a lot of the ledgers have the same "last entry id"
----
2019-03-28 17:20:47 UTC - Emma Pollum: Looks like one of our global zks is out 
with the error "Mar 28 17:19:21 p-zookeeper-3 zkServer.sh[18195]: Caused by: 
java.io.IOException: Unreasonable length = 1527340800"
----
2019-03-28 17:43:11 UTC - bhagesharora: Hello everyone,
I am trying to implement pulsar-kafka-adaptor program through java
Reference URL - 
<https://github.com/apache/pulsar/blob/master/pulsar-client-kafka-compat/pulsar-client-kafka-tests/pom.xml>

I had given maven build But its giving error, see below
[ERROR] Failed to execute goal on project pulsar_kafka_adaptor: Could not 
resolve dependencies for project 
pulsar_kafka_adaptor:pulsar_kafka_adaptor:jar:0.0.2-SNAPSHOT: Failed to collect 
dependencies for pulsar_kafka_adaptor:pulsar_kafka_adaptor:jar:0.0.2-SNAPSHOT: 
Could not resolve version conflict among 
[org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
org.apache.bookkeeper:stream-storage-server:jar:4.9.0 -&gt; 
org.apache.bookkeeper:stream-storage-java-client:jar:4.9.0 -&gt; 
io.grpc:grpc-core:jar:1.12.0, org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
org.apache.bookkeeper:stream-storage-server:jar:4.9.0 -&gt; 
org.apache.bookkeeper:stream-storage-java-client:jar:4.9.0 -&gt; 
io.grpc:grpc-protobuf-lite:jar:1.12.0 -&gt; io.grpc:grpc-core:jar:1.12.0, 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
org.apache.bookkeeper:stream-storage-server:jar:4.9.0 -&gt; 
org.apache.bookkeeper:stream-storage-java-client:jar:4.9.0 -&gt; 
io.grpc:grpc-testing:jar:1.12.0 -&gt; io.grpc:grpc-core:jar:[1.12.0,1.12.0], 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-auth:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:[1.18.0,1.18.0], 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-core:jar:[1.18.0,1.18.0], 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-netty:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:[1.18.0,1.18.0], 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-okhttp:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:[1.18.0,1.18.0], 
org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-protobuf:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:1.18.0, org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-protobuf-nano:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:1.18.0, org.apache.pulsar:pulsar-broker:jar:2.3.0 -&gt; 
org.apache.pulsar:pulsar-zookeeper-utils:jar:2.3.0 -&gt; 
io.grpc:grpc-all:jar:1.18.0 -&gt; io.grpc:grpc-stub:jar:1.18.0 -&gt; 
io.grpc:grpc-core:jar:1.18.0] -&gt; [Help 1]

what would be the solution ??
----
2019-03-28 18:06:58 UTC - Vikas: hey @David Kjerrumgaard, how are you!
I am unable to send the data to the pulsar topic using NiFi and getting the 
error as :
Policies not found for alpha/xxx-xxxxx namespace

Do you know what am I missing?
----
2019-03-28 18:10:26 UTC - David Kjerrumgaard: Hi @Vikas I am OOO this week but 
can take a look this weekend. Can you share the pulsar and nifi logs?
----
2019-03-28 18:11:15 UTC - David Kjerrumgaard: Did you configure any polices on 
that namespace?
----
2019-03-28 18:11:32 UTC - Vikas: sure, I can share with you the NiFi logs but 
dont have access to the pulsar logs as its the production system. I can 
definitely ask the person who takes care of the pulsar system
----
2019-03-28 18:12:12 UTC - David Kjerrumgaard: The issue appears to be related 
to Pulsar policies 
----
2019-03-28 18:12:31 UTC - Vikas: oh ok, let me ask him. Sorry to bug you on 
your holidays.
----
2019-03-28 18:12:37 UTC - Vikas: enjoy :smile:
----
2019-03-28 20:44:17 UTC - Devin G. Bost: @Devin G. Bost has joined the channel
----
2019-03-28 20:44:44 UTC - Grant Wu: Are the Python docs at 
<https://pulsar.apache.org/api/python> out of date?
----
2019-03-28 20:45:15 UTC - Grant Wu: Poring over the diffs between the 2.2.1 tag 
and the 2.3.0 tag, I see this:
```
diff --git a/pulsar-client-cpp/python/src/message.cc 
b/pulsar-client-cpp/python/src/message.cc
index 42322490e..19aa7bb2b 100644
--- a/pulsar-client-cpp/python/src/message.cc
+++ b/pulsar-client-cpp/python/src/message.cc
@@ -66,6 +66,20 @@ boost::python::object Message_data(const Message&amp; msg) {
     return 
boost::python::object(boost::python::handle&lt;&gt;(PyBytes_FromStringAndSize((const
 char*)msg.getData(), msg.getLength())));
 }

+boost::python::object Message_properties(const Message&amp; msg) {
+    boost::python::dict pyProperties;
+    for (const auto&amp; item : msg.getProperties()) {
+        pyProperties[item.first] = item.second;
+    }
+    return pyProperties;
+}
+
+std::string Topic_name_str(const Message&amp; msg) {
+    std::stringstream ss;
+    ss &lt;&lt; msg.getTopicName();
+    return ss.str();
+}
+
 const MessageId&amp; Message_getMessageId(const Message&amp; msg) {
     return msg.getMessageId();
 }
@@ -109,7 +123,7 @@ void export_message() {
             ;

     class_&lt;Message&gt;("Message")
-            .def("properties", &amp;Message::getProperties, 
return_value_policy&lt;copy_const_reference&gt;())
+            .def("properties", &amp;Message_properties)
             .def("data", &amp;Message_data)
             .def("length", &amp;Message::getLength)
             .def("partition_key", &amp;Message::getPartitionKey, 
return_value_policy&lt;copy_const_reference&gt;())
@@ -117,5 +131,6 @@ void export_message() {
             .def("event_timestamp", &amp;Message::getEventTimestamp)
             .def("message_id", &amp;Message_getMessageId, 
return_value_policy&lt;copy_const_reference&gt;())
             .def("__str__", &amp;Message_str)
+            .def("topic_name", &amp;Topic_name_str)
             ;
 }
```
----
2019-03-28 20:45:19 UTC - Matteo Merli: They shouldn’t. Do you see anything 
missing thee?
----
2019-03-28 20:45:29 UTC - Grant Wu: But the `topic_name` function isn’t in the 
docs
----
2019-03-28 20:45:36 UTC - Grant Wu: Refer to thread
----
2019-03-28 20:47:53 UTC - Devin G. Bost: My team is trying to figure out how to 
delete subscriptions. We're getting:
```
Failed to perform http delete request: javax.ws.rs.ClientErrorException: HTTP 
412 Precondition Failed
Subscription has active connected consumers

Reason: Subscription has active connected consumers
```
We've tried terminating the topic first, but we're still missing something, and 
we can't find anything in the docs about it.
----
2019-03-28 20:49:06 UTC - Matteo Merli: If a consumer is connected, the 
deletion fails. That’s Because the consumers will immediately try to reconnect 
and recreate the subscription 
----
2019-03-28 20:49:24 UTC - Devin G. Bost: Gotcha. How do we disconnect the 
consumers?
----
2019-03-28 20:50:05 UTC - Devin G. Bost: Is there a forceful way to do that? 
We're trying to wipe a deployment and re-deploy via automation.
----
2019-03-28 20:50:42 UTC - Matteo Merli: There a way to force the topic deletion
----
2019-03-28 20:51:27 UTC - Matteo Merli: Disconnecting consumer is just shutting 
down the application is consuming :)
----
2019-03-28 20:52:23 UTC - Devin G. Bost: There is, or there is not a way to 
force the topic deletion? Sorry, I'm not understanding your comment.
----
2019-03-28 21:00:57 UTC - Devin G. Bost: It looks like our deletions are only 
breaking on:

```
<persistent://public/functions/coordinate>
<persistent://public/functions/assignments>
<persistent://public/functions/metadata>
```
So, maybe my question is moot.
----
2019-03-28 21:01:46 UTC - Matteo Merli: These are topics use by pulsar 
functions runtime. 
+1 : Devin G. Bost
----
2019-03-28 21:08:04 UTC - Grant Wu: @Matteo Merli try `git diff tags/v2.2.1 
tags/v2.3.0 -- pulsar-client-cpp/python/pulsar`
----
2019-03-28 21:08:42 UTC - Grant Wu: and that should get a bunch of stuff 
missing…
----
2019-03-28 21:23:02 UTC - Grant Wu: Anyone know how to build the Python docs?
----
2019-03-28 21:27:48 UTC - Ali Ahmed: @bhagesharora  seems like 
“io.grpc:grpc-core:jar:1.12.0” “io.grpc:grpc-all:jar:1.18.0" is the issue
----
2019-03-28 21:28:08 UTC - Ali Ahmed: is this in master ? or some new modified 
pom
----
2019-03-28 21:52:16 UTC - Florian Hof: @Florian Hof has joined the channel
----
2019-03-28 21:58:04 UTC - Florian Hof: How big can a message be? Is 500MB ok? 
Is Pulsar suitable as a document-based database with long retention (more than 
one year)? Thanks for feedback :slightly_smiling_face:
----
2019-03-28 21:58:39 UTC - Ali Ahmed: @Florian Hof messages size is currently 
limited to 5MB
----
2019-03-28 22:01:18 UTC - Ali Ahmed: @bhagesharora this may help
```
    &lt;!--Adding dependencyManagement to resolve conflicts --&gt;
    &lt;dependencyManagement&gt;
        &lt;dependencies&gt;
          &lt;dependency&gt;
              &lt;groupId&gt;io.grpc&lt;/groupId&gt;
              &lt;artifactId&gt;grpc-core&lt;/artifactId&gt;
              &lt;version&gt;1.2.0&lt;/version&gt;
          &lt;/dependency&gt;
        &lt;/dependencies&gt;
    &lt;/dependencyManagement&gt;
```
----
2019-03-28 22:02:19 UTC - Grant Wu: I’m not sure why you would want to use 
Pulsar as a document-based database
----
2019-03-28 22:07:43 UTC - Emma Pollum: After a crashed zk, we are left without 
access to messages that are still in bookkeeper. Does anyone have any thoughts 
on the best way to extract them? Essentially, all the data in the bookeeper is 
fine, but there is no reference to it under /managed-ledgers in zk.
----
2019-03-28 22:09:16 UTC - Florian Hof: @Grant Wu I was looking for a messaging 
system with long-term storage for big messages (100MB). Ok, Pulsar is definitly 
not done for that.
----
2019-03-28 22:09:54 UTC - Grant Wu: It’s not clear to me why you wouldn’t use a 
traditional database for this use case
----
2019-03-28 22:11:54 UTC - Ryan Samo: Do Pulsar clients cache DNS? Meaning if 
you have DNS being used between all of the server nodes, brokers, etc., will 
the clients cache the IP of the last broker they talked to? Just thinking in 
terms of if you have an outage on a broker and the client cached the IP, it can 
take up the TTL of the DNS before a client figures that out. Thoughts?
----
2019-03-28 22:14:26 UTC - Grant Wu: Hey, @Laurent Chriqui are you around?
----
2019-03-28 22:14:36 UTC - Grant Wu: I’m running into
```
ImportError: 
dlopen(/Users/grant.wu/petuum/sps_venv/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so,
 2): Symbol not found: __ZN6icu_636LocaleC1ERKS0_
  Referenced from: 
/Users/grant.wu/petuum/sps_venv/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
  Expected in: flat namespace
 in 
/Users/grant.wu/petuum/sps_venv/lib/python3.7/site-packages/_pulsar.cpython-37m-darwin.so
```
----
2019-03-28 22:14:41 UTC - Grant Wu: and I think you encountered this before?
----
2019-03-28 22:15:35 UTC - Grant Wu: I think it’s in this thread
<https://lists.apache.org/thread.html/63f3ce8255958d30d3ee75c2e63bc04ced1da65d7e4c1e522fc29b27@%3Cusers.pulsar.apache.org%3E>
----
2019-03-28 22:17:13 UTC - Grant Wu: I’m going to try `brew upgrade`
----
2019-03-28 22:17:16 UTC - Grant Wu: see if that fixes anything
----
2019-03-28 22:32:13 UTC - Grant Wu: ah okay I need the `.post1` version
ok_hand : Laurent Chriqui
----
2019-03-28 22:43:49 UTC - Matteo Merli: Uhm, you’re right. that’s way off :?
----
2019-03-28 22:43:52 UTC - Matteo Merli: :confused:
----
2019-03-28 22:45:17 UTC - Matteo Merli: 
<https://github.com/apache/pulsar/tree/asf-site/content/api/python>
----
2019-03-28 22:45:43 UTC - Matteo Merli: It looks like the website build is not 
updating the docs correctly
----
2019-03-28 22:53:49 UTC - Grant Wu: Is there an easy way to build them locally?
----
2019-03-28 22:54:15 UTC - Matteo Merli: There’s a command that builds it on a 
docker image
----
2019-03-28 22:54:22 UTC - Matteo Merli: let me search for it
----
2019-03-28 22:54:56 UTC - Matteo Merli: essentially it’s calling the `pdoc` tool
----
2019-03-28 22:55:09 UTC - Matteo Merli: `site2/tools/docker-build-site.sh`
----
2019-03-28 22:55:41 UTC - Matteo Merli: `site2/tools/publish-website.sh` it’s 
the one that does the publish.. which is probably where it’s currently broken
----
2019-03-28 23:23:21 UTC - Grant Wu: I tried to build it in docker and I got
```
c++: internal compiler error: Killed (program cc1plus)
```
----
2019-03-28 23:23:39 UTC - Grant Wu: I imagine this is probably an OOM?
----
2019-03-28 23:23:57 UTC - Grant Wu: Surely it should be possible to build the 
docs without building the world ;-;
----
2019-03-28 23:26:34 UTC - Ezequiel Lovelle: afaik, java client uses connection 
pool to handle connections towards every broker-topic.
Dns resolution will occur (the first time) when calling `create()` for 
producers and `subscribe()` for consumers and no cache is involved on dns 
resolution I think.
So, clients will try to do re-connection on broker outage, and this process 
will start again doing new dns resolution.

But please, don't take this to be final and wait if anyone have more 
information about this.
----
2019-03-28 23:28:53 UTC - Ryan Samo: Ok thanks @Ezequiel Lovelle , this is the 
behavior I see in my testing so looking for a sanity check from the community. 
I’ll wait and see if anyone else adds information 
+1 : Ezequiel Lovelle
----
2019-03-28 23:41:11 UTC - Grant Wu: @Matteo Merli Is there… any sort of 
documentation as to how to use JSON Schemas with the pulsar 2.3.0 client?  I’m 
looking at `definition.py` and it seems like it’s using a metaclass approach?

Personally all I want is to ser/deser stuff to dictionaries.. at least for now
----
2019-03-28 23:41:25 UTC - Matteo Merli: :slightly_smiling_face:
----
2019-03-28 23:41:55 UTC - Matteo Merli: it’s building the C++ library to have 
the _pulsar.so to be imported
----
2019-03-28 23:42:10 UTC - Grant Wu: 
<https://pulsar.apache.org/docs/en/concepts-schema-registry/> says “The Pulsar 
schema registry is currently available only for the Java client.” - is this 
still the case?
----
2019-03-28 23:43:04 UTC - Matteo Merli: @Grant Wu 
<https://pulsar.apache.org/docs/en/client-libraries-python/#schema>
----
2019-03-28 23:43:32 UTC - Matteo Merli: yes.. the above line is now inaccurate
----
2019-03-28 23:44:25 UTC - Grant Wu: Oh, right, I forgot there were 
non-generated Python docs…
----
2019-03-28 23:48:23 UTC - Grant Wu: If I have a client that doesn’t know 
anything about schemas - say, it uses the websocket interface, or the Go client 
- will problems arise if it tries to consume from a topic with a schema?
----
2019-03-28 23:49:42 UTC - Grant Wu: If I want to use a purely client-side 
approach for now, can I just pass in `None` for the third parameter to the 
Schema class constructor?
----
2019-03-28 23:49:55 UTC - Grant Wu: as `BytesSchema` and `StringSchema` are 
doing
----
2019-03-29 01:47:59 UTC - jia zhai: Thanks @Steve Kim for the work.
----
2019-03-29 04:40:33 UTC - Yuvaraj Loganathan: @Emma Pollum What do you mean by 
crashed zk ? ZK persists all the data to disk. rebooting zk should solve or did 
not bring the data back? how many nodes are there in zk cluster ?
----
2019-03-29 05:35:50 UTC - David Tinker: Can the Bookkeeper ledgers directory 
configured in bookkeeper.conf be a symlink to a directory on a different 
filesystem?
----
2019-03-29 05:39:43 UTC - Sijie Guo: @David Tinker yes
+1 : David Tinker, Guangzhong Yao
----
2019-03-29 06:07:25 UTC - Shubham Maheshwari: Hi @Ezequiel Lovelle.. if I do 
that, I'll end up creating multiple subscriptions to the topic. I do not want 
that. I want a single subscription with multiple consumer threads running for it
----
2019-03-29 06:07:47 UTC - Shubham Maheshwari: btw .. this works fine in the 
previous version.
----

Reply via email to