Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/189
In my comments I called journal dirs. but infact they are ledger dirs.
Typos from my side.
As far as journals are concerned, we can have only one journal dir right?
@reddycharan what do you
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/189
Multiple entrylog change is coming in and Charan is using this for that. So
you can think of this as setting stage for that.
If you don't want to have the flag/configuration parameter we can
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/200
@sijie what is the major drive of this change? Current method of trying
speculative reads has any major flaw? I understand this is better organized as
speculative reads has its own policy
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/189
@sijie @reddycharan Let me step back and discuss this.
1. Are there any legitimate use cases of specifying multiple ledger dirs on
the same disk partition? if not, in production I would
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/210
We are adding REST endpoint to BookKeeper. I need to check if they overlap.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/189
Right. So if there are two dirs /journal1 and /journal2 both were created
on the same disk.
With the dedup, we will choose only one say, /journal1 and /journal2 is
always kept empty. Am
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/189
The flag is to allow backward compatibility and warn the user if they
configured multiple journal dirs on the same partition by mistake. Per @sijie's
point, yes we can handle them by monitoring
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/178
LGTM
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/168
Is the plan to move to Travis from Jenkins?? Any reason to go with Travis
instead of Circle?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/179
can't we come up with a macro to wrap this? Chane looks fine to me though.
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/175
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/issues/165
Sorry for being naive on this subject. What is the real use of implementing
tutorial in Scala? and have a separate git repo for it?
---
If your project is set up for it, you can reply
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/153
Interesting and on the paper sounds great. But do we have any perf testing
or benchmark? I believe we need to have a benchmark / ref to run and compare
any perf improvements. I have seen extremely
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/154
Awesome!! @kishorekasi
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/145
On Thu, May 11, 2017 at 8:09 AM Matteo Merli <notificati...@github.com>
wrote:
> @jvrao <https://github.com/jvrao> I agree with the point of separating
> t
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/145
We (plan to) use error messages to do a lot of post processing. We would
like to see all errors logged as it has much more information than pure log
message.
On Wed, May 10, 2017
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/141
Ok so you are talking about your own production issue. But I don't believe
it is right thing to change production code to speed up testing. I believe we
need more elaborate fix to take care
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/141
Can someone explain me why it won't affect production bookies?
@eolivelli ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/145
What about the regular read failure? We need a way to print the error
message on regular read request and ignore in recovery case or where we try to
read beyond LAC. Changing to default by default
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/146
@athanatos did we do the same fix internally?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/138
Nice work!! Finally everything is passing. :) Great news.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/149
@athanatos FYI
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/114
+1
On Fri, Apr 28, 2017 at 4:58 AM, Enrico Olivelli <notificati...@github.com>
wrote:
> So it seems that this patch contains the fix for the failing tests on
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/114
This looks lot cleaner to me. Thanks for making changes as per review
comments. I will ping Charan once again for his final OK.
On Tue, Apr 18, 2017 at 8:29 AM, Enrico Olivelli
24 matches
Mail list logo
