Slower than Catch in realistic test cases

Hi,
I did some benchmarking of doctest on my machine (Linux, gcc-4.9.3). I adapted a bit your Python script to work on Linux (with_gcc = 1 and removed the forced CMake generator).
First, I can confirm that in the simple benchmark case, it is indeed faster to compile than Catch by a large margin. However, this is not a very realistic test case.
I have modified the benchmark to generate 50 files, each with 25 test cases and each with 10 CHECK (using a variable and not two constants). Here are the results:
Catch: 1 minute 56 seconds
Doctest: 2 minutes 32 seconds
In a realistic test case, doctest is significantly slower than Catch. I can see the same thing when I replace Catch by doctest in one of my large test case of my ETL library.
Do you have any idea why this happen ?
I can only guess that the overhead comes from the templates used to extract lhs and rhs or by the macros generating the test cases.

It should be because of the macros and code bloat - currently the CHECK/REQUIRE macros generate more code than they should - this is a planned optimisation - and when I fix this - it should be on-par with Catch for heavy usage as well - but making it any faster is maybe impossible.
see the comparison in code generated by the macros - doctest versus catch
A step further for even faster compile times would be to introduce macros like CHECK_EQUALS(x, y) where there is no expression decomposition and less templates - a blog post on this matter regarding Catch can be read here (and actually you are the author :D).

It should be because of the macros and code bloat - currently the CHECK/REQUIRE macros generate more code than they should - this is a planned optimisation - and when I fix this - it should be on-par with Catch for heavy usage as well - but making it any faster is maybe impossible.

You're probably right, a bit of encapsulation would save some compilation time if this block of code is not compiled for every assertion.

A step further for even faster compile times would be to introduce macros like CHECK_EQUALS(x, y) where there is no expression decomposition and less templates - a blog post on this matter regarding Catch can be read here (and actually you are the author :D).

This is me indeed :) I was very surprised to find such a large improvement.
CHECK_EQUALS and a few variants would probably be the best solution to save the maximum compilation time. That would also mean more variants to maintain on the library side.
Thanks for the time invested so far and congratulations for the very fast include times :)

If you are interested, I have been able to reduce the compilation time even further: http://baptiste-wicht.com/posts/2016/06/reduce-compilation-time-by-another-16-with-catch.html
I have reduced the REQUIRE_EQUALS macro even further for another 16% reduction in compilation, this is a total of 27% reduction from the original compilation time of 764 seconds to 554 seconds.

I will probably supply such macros in a separate header as an extension - but before that I will optimize the current macros

100 files
25 tests
10 assertions
variables and assertions like this:
int a0 = 5;
int b0 = 6;
CHECK(a0 == b0);
int a1 = 5;
int b1 = 6;
CHECK(a1 == b1);

MSVC Debug - 13 sec (old was 19 sec)
MSVC Release - 21.7 sec (old was 38 sec)
MinGW-w64 GCC 5.3.1 Debug - 47 sec (old was 100 sec)
MinGW-w64 GCC 5.3.1 Release - 150 sec (old was 330 sec)
Catch:
MSVC Debug - 62 sec
MSVC Release - 123 sec
So the dev version of doctest should now be quite faster than it's previous version (by around 40% for MSVC and 53% for MinGW-w64 gcc 5.3.1) - even though Catch is slower than both the old and the new version of doctest according to my benchmarks - but I suspect they still ain't real enough.
The single header is now assembled from it's 2 parts - doctest/parts/doctest_fwd.h and doctest/parts/doctest_impl.h - to get optimal compile time performance include the fwd version everywhere and the impl version only where the test runner should be instantiated. But for these benchmarks here I used the single header and not the parts.
I'm going to make a header - doctest/parts/doctest_ext.h with fast versions of the macros just like your fast_catch.hpp header - for equality, less than, greater than, etc.
But I'm not sure if I should circumvent the Approx class like you have done - if I don't use that class I will have to include <cmath> for abs() and etc...
All this is in the dev branch - I will make a 1.1 release soon (in the upcoming weeks) and this will go into it.
Thanks for pushing me to optimize this - it was on the roadmap but I only suspected it was slower - didn't have a clue how much.
What do you think? Test it in your codebase and report :)

Sooo I made the first set of macros in the doctest/doctest/parts/doctest_fast.h header - WARN_EQ/CHECK_EQ/REQUIRE_EQ
and here are some compile time benchmarks with MSVC 2015 in Debug (no other compilers/modes tested):
500 files
25 test cases per file
10 assertions per case
93 sec (expression decomposition) vs 35 sec (fast macros) - but the majority of the time in the slow case is spent in linking
1 file
250 test cases in that file
100 assertions per case
48 sec (expression decomposition) vs 4.6 sec (fast macros) - majority of time spent NOT in linking - but in compiling!!!
And I even retained all the functionality of the macros - they break into the debugger and the REQUIRE_EQ macro ends the test case on failure! I could have made it even more optimal but I don't want to cut away these features.
Give it a try and report what happens in the real world :)
I will make macros also for less than/greater than/etc. soon.

I ended up removing the doctest_fast.h header and now the fast macros are in the main doctest header - see here

This sounds great! I'm in vacation now, but I'll test this on my codebase next week.

I've been able to test the last version directly on my codebase. I made it so I just have to define a macro to switch between Catch and doctest.
Here are the timings:

Catch: ~650s
Catch (fast macros): ~460s
Doctest: ~440s
Doctest (stripped macros): ~410s

(The timings are not the same from my blog post because I did this experiment with less features enabled)
So, it's faster than Catch in all cases! Even in the case when using my very minimal Catch macros, it's faster and has more features (since you retained much more features than I did).
The stripped macros are stripped so that they contain only the call to fast_assert and fast_assert_unary. Not sure if it's worth doing for me and certainly not worth doing in the library itself.
I had to do one change though. In fast_assert_unary, you are taking the expression by reference and then converting bool inside. The problem with that is that the expression is odr-used and in my case this leads to undefined references at link time with fields that should not be odr-used. The same problem could occur in fast_assert, but I don't compare binary things that cannot be odr-used in my case. I simply did a new version of fast_assert with a bool value as parameter. Is it really important to do the conversion to bool inside fast_assert than simply taking a bool parameter ?

well if fast_assert_unary takes a bool - then the try/catch block where it is evaluated will go out of the function and into the macro - leading to more code bloat.
about the odr-used stuff - can you give an example? I'm a bit brain-dead at the moment

well if fast_assert_unary takes a bool - then the try/catch block where it is evaluated will go out of the function and into the macro - leading to more code bloat.

But only the conversion to bool will be evaluated at this place, not the evaluation of the expression itself, isn't it ?
If you have a function f(x) that returns a bool, the evaluation of f(x) inside REQUIRE_UNARY(f(22)) will not be evaluated inside the try/catch block, but only inside the DOCTEST_FAST_ASSERTION_UNARY. Only the bool will then be passed to fast_assert_unary and therefore the try catch should not catch anything. The only thing that would be caught by your try/catch is an exception  thrown by the conversion of the passed value to bool and in most cases, this will simply be a bool.

about the odr-used stuff - can you give an example? I'm a bit brain-dead at the moment

Yes. Imagine you are testing type_traits:
template<typename T>
struct type_traits {
    static constexpr const bool is_bounded = false;
};

somewhere:
    REQUIRE_UNARY(type_traits<double>::is_bounded);
    REQUIRE_UNARY(type_traits<float>::is_bounded);

In this case, there is an undefined reference because is_bounded is "used" (because of the reference to it), its value cannot be directly replaced by the compiler. And therefore a definition should be present. This is not a huge issue, since in most cases, the definition will be available. This is mostly a corner case and I can deal with it myself I guess.

damn - I completely missed both of these things...
I'll have to think on this.
I think I'll end up making 2 sets of assertions - those who can catch exceptions - in the macro, and those that cant - the fast ones.
And maybe the user will switch between them with a define, or they will be separate macros - perhaps CHECK_EQ and CHECK_EQ_FAST...

damn - I completely missed both of these things...
I'll have to think on this.

Sorry to give you so much work ;)
As for the reference problem, it's probably secondary. The first problem is more important for people who care about exceptions.

after 3+ months of radio silence - I've fixed all the new assertions!
checkout the benchmarks!
roughly said:
doctest 1.1 (which will be released today probably) is around 3 times faster than version 1.0 (released on 2016.05.22) when expression decomposing macros like CHECK(a==b) are used.
Additionally I've added normal binary macros that don't do any expression decomposition - CHECK_EQ(a,b) - and they are around 20% faster than CHECK(a==b). These macros capture exceptions thrown while evaluating the expression (and it's left and right side) - just like CHECK(a==b).
Additionally I've added faster normal binary macros that don't do any expression decomposition - FAST_CHECK_EQ(a,b) - and they are around 30-70% faster than CHECK_EQ(a,b)! The difference is that these macros don't have a try/catch block so no exceptions are caught.
Additionally I've added the DOCTEST_CONFIG_SUPER_FAST_ASSERTS identifier which makes the fast asserts even faster by another 20-80%! The difference is that when such super fast assertions fail - if the debugger is attached it will not break on the source line where the assertion was written but in a function inside doctest - so the user will have to go 1 level up in the callstack to see where the failing assertion actually is.
I've also added the DOCTEST_CONFIG_ASSERTION_PARAMETERS_BY_VALUE config identifier - when used all expressions are copied instead of binded to const& - so no ODR usage - like you've requested.
All macros evaluate the expressions only once. All macros stringify properly the values when the assertion fails.
Let me know what you think! :)

That sounds so awesome!
As soon as the version 1.1 is released, I'll update my code and do the measurements again and make a post on my blog. I'll keep you up-to-date with the results.

A blog post would be much appreciated - any kind of publicity for this framework is much needed!
damn rebasing... I should really learn git.

I made all the tests. The results are available on my blog: http://baptiste-wicht.com/posts/2016/09/blazing-fast-unit-test-compilation-with-doctest-11.html
For reference, here are the final results I got (on my expression templates framework):
Catch 724.22
Fast Catch macros 464.52
doctest 1.0 871.54
doctest 1.1 614.67
REQUIRE_EQ 	493.97
FAST_REQUIRE_EQ 439.09
SUPER_FAST_ASSERTS 411.11
That's pretty good results, I think.

damn - nothing compared to my synthetic benchmarks :D but still - my fastest macros are just a single function call - just like the ones u've made for Catch. I should make a note in the documentation that for real use cases the results are not that spectacular :D

I think it's still great. Here, we are still compiling more than 1000 test case with several thousand assertions. Moreover, this a template-heavy library so we can expect some lengthy compilation times. If we could compute the real compilation of the test cases without the test (:P), then we could compare the real difference between catch and doctest.


test comments

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

It is a long established fact that a reader will be distracted by the readable content of a page when looking at its layout. The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here', making it look like readable English. Many desktop publishing packages and web page editors now use Lorem Ipsum as their default model text, and a search for 'lorem ipsum' will uncover many web sites still in their infancy. Various versions have evolved over the years, sometimes by accident, sometimes on purpose (injected humour and the like).


Tasks and Goals - Linked (assets) Concerns and associations

Expected behaviour
Assuming the CAIRIS project was first built using/linking assets (systems, people data etc) -
When creating a Task, you can associate its related/dependent assets "Concerns" first, and then where an asset 'has a' relation/dependency with another.
You can also create a matching main Goal (and sub-goals) and again associate its related/dependent assets "Concerns" first, and then where an asset 'has a' relation/dependency with another.
Actual behaviour
This is actually a lot of work and duplication (more so with multiple views), which you then do again (or duplicate) when creating the Goal. If as a user I may then be subject to human error, what if I didn't associate the asset and its related asset in the same way in the Task and the Goal. Is there something in CAIRIS that may highlight this problem. AND, is this different or a problem to how assets were originally associated/related in the Asset modelling? This is main question.
Moreover, this still assumes I am from Bravo. But what if Charlie does something similar in their view (being used external to Bravo). If we joined these views later (perhaps as per the current 'Overview' environment), we may want some alarm bells to show conflicts not just for the independent system, but also the SoS (albeit, the view is one big system to CAIRIS, so the point is the same either way)
Steps to reproduce the behaviour
An example of this is in TMN20180329, e.g. (Charlie)(F1) & (F2) Main Goals and its related Tasks. Although, as these were last few after many, when I realised I had the wrong relation, I corrected it and moved on (although didn't see anything odd in the models to alert me), so I would need to purposely add this in again to test for issues. I thought it may be useful feedback though.
Version of CAIRIS
Git Pull on 28 March 2018
Operating Systems / Hardware
Windows 7 with VMware using Ubuntu17 and Linux Chrome

If I read this correctly, you have created a task (everyday work activity) and added a task concern from an asset (A1), created a goal with the same name as the task (everyday work activity), and you want to automatically add a goal concern, linking A1 to this goal, because it shares the same name as the pre-existing task.
I'm not convinced this is a good idea, for a number of reasons:

Goals and tasks are conceptually different things.  Goals are goals the system needs to satisfy.  Tasks describe work which is carried out, presumably when goals are satisfied.
It seems you should really be thinking about what goals need to be satisfied for everyday work activity to run to its conclusion as you've written it, i.e. you should be working bottom-up rather than top-down.   Tasks are carried out by people, who may choose not to carry out the task.  Making the satisfaction of system goals contingent on the successful completion of a task (rather than the other way around) could get very messy.

Does this make sense?


Selects the wrong slot

Do you want to request a feature or report a bug?
bug
What's the current behavior?
selecting the wrong slot. about 5 hours behind I think.
Using moment-timezone for localizer and latest react-big-calendar

What's the expected behavior?

Using Timezones with Big Calendar


Error: Test result not found when using parameterized fixtures

Environment data

VS Code version: 1.59.0
Extension version (available under the Extensions sidebar): v2021.9.1137256656-dev
OS and version: Ubuntu 18.04
Python version (& distribution if applicable, e.g. Anaconda): python 3.8.10, conda 4.10.3
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
Relevant/affected Python packages and their versions: pytest 6.2.4
Relevant/affected Python-related VS Code extensions and their versions: Python (version above)
Value of the python.languageServer setting: Pylance

[NOTE: If you suspect that your issue is related to the Microsoft Python Language Server (python.languageServer: 'Microsoft'), please download our new language server Pylance from the VS Code marketplace to see if that fixes your issue]
Expected behaviour
I'm using a parameterized fixture for my package, which runs tests against a group of valid configuration files
# tests/conftest.py
import pytest
import yaml

approved_config_list = [
    "experiments/config.yml",
    "experiments/model_v1.0.yml",
]

@pytest.fixture(params=approved_config_list)
def config(request):
    with open(request.param) as fd:
        cfg = yaml.safe_load(fd)
    return cfg

Actual behaviour
All of my tests are passing, however, for each parameterized test I get something like:
Test result not found for: ./tests/test_postprocessing.py::TestPostprocessing::test_input_type[experiments/config.yml]
If I remove the parameterization here then the testing sidebar finds all of the test results just fine and confirms they all succeeded.  The test log output also has no issues and says everything passed.
Steps to reproduce:
I think writing some simple pytests with these files should reproduce this and also use the same characters in the params in case it's a special character issue.
# tests/conftest.py
import pytest
import yaml

approved_config_list = [
    "experiments/config.yml",
    "experiments/model_v1.0.yml",
]

@pytest.fixture(params=approved_config_list)
def config(request):
    with open(request.param) as fd:
        cfg = yaml.safe_load(fd)
    return cfg

# tests/test_file.py

class TestConfig:
    def test_config(self, config):
        assert isinstance(config, dict)

# experiments/config.yml
attr1: 1
attr2: 2

# experments/model_v1.0.yml
attr1: 1
attr2: 3

# .vscode/launch.json
{
    "python.testing.pytestEnabled": true,
    "python.testing.pytestArgs": [
        "tests"
    ],
}

I think I have found the issue, it is the forward slash character in the params

Can you verify using this VSIX: https://github.com/microsoft/vscode-python/suites/3584266029/artifacts/86250061 ?

I am experiencing a similar issue in all my tests, being them parametrized with fixtures or not. I have my repo divided in multiple workspaces, so I am not sure this issue might be related to that.

@jzazo Can you file a separate bug and provide repro details?

I have created the following issue with repro details: https://github.com/microsoft/vscode-jupyter/issues/7424
Thanks.

@karthiknadig I am still experiencing this issue. I don't have any slashed in my params.
Do you want a reproducible example?
My last update is apparently (but not sure how to really check it): 04/11/2021, 19:40:15. Is it enough to have the fix to this problem?


Django-Taggit & Django-Filter causes AssertionError: resolved field 'tags' with 'exact' lookup to an unrecognized field type TaggableManager

Hello Everybody,
I wish to use Django-Filter together with Django-Taggit, unfortunately, it causes a problem:

AssertionError: PostFilter resolved field 'tags' with 'exact' lookup to an unrecognized field type TaggableManager. Try adding an override to 'Meta.filter_overrides'. See: https://django-filter.readthedocs.io/en/master/ref/filterset.html#customise-filter-generation-with-filter-overrides

Here is my code:
#models.py
from taggit.managers import TaggableManager
    class Post(models.Model):
        title    = models.CharField(max_length = 200)
        text     = models.TextField(null = True, blank = True)
        tags     = TaggableManager()

        def __str__(self):
            return self.title

#forms.py
class PostForm(ModelForm):
    class Meta:
        model = Post
        fields = '__all__'

#filter.py
class PostFilter(django_filters.FilterSet):
    class Meta:
        model = Post
        fields = ['title', 'text']

#views.py
def index(request):
    posts = Post.objects.all()
    myFilter = PostFilter(request.GET, queryset=posts)
    posts = myFilter.qs
    context = {'posts':posts, 'myFilter':myFilter}
    return render(request, 'posts/index.html', context)

If I write "exclude = ['tags']" in filter.py the problem goes away, sure - but that defeats the purpose since I would like to be able to filter by tags. Is that possible with django-filter?
Thanks in advance!

I think here the problem is you don't have builtin support for tags with django-filter. However, if you go to that link you'll find that you could specify a filter for like (spitballing here but I think it would work):
class PostFilter(django_filters.FilterSet):
    class Meta:
        model = Post
        fields = ['title', 'text', 'tags']
        filter_overrides = {
             TagField: { # TODO you'll need to look up the exact model field
                 'filter_class': django_filters.CharFilter,
                 'extra': lambda f: {
                     'lookup_expr': 'name__icontains', # here we're saying to look through the icontains prop on name
                 },
             },

         }


[Question] How to specify already existing portgroup for the cloned virtual machine?

Hi,
Could you help me to find an example how I can specify already existing portgroup during virtual machine cloning?
This is how I find my portgroup:
get_obj(content, [vim.Network], "<IP_ADDRESS>s24v1960")

And I have this piece of code:
    device = []

    nic = vim.vm.device.VirtualDeviceSpec()
    nic.operation = vim.vm.device.VirtualDeviceSpec.Operation.edit
    nic.device = vim.vm.device.VirtualVmxnet3()
    nic.device.wakeOnLanEnabled = True
    nic.device.addressType = 'assigned'
    nic.device.key = 4000  # 4000 seems to be the value to use for a vmxnet3 device
    nic.device.deviceInfo = vim.Description()
    nic.device.deviceInfo.label = "Network Adapter 555"
    nic.device.deviceInfo.summary = "Some Device Name"
    nic.device.backing = vim.vm.device.VirtualEthernetCard.NetworkBackingInfo()
    nic.device.backing.network = get_obj(content, [vim.Network], "<IP_ADDRESS>s24v1960")
    nic.device.backing.deviceName = "Some Device Name"
    nic.device.backing.useAutoDetect = False
    nic.device.connectable = vim.vm.device.VirtualDevice.ConnectInfo()
    nic.device.connectable.startConnected = True
    nic.device.connectable.allowGuestControl = True
    devices.append(nic)

    vmconf = vim.vm.ConfigSpec(deviceChange=devices, numCPUs=cpus, memoryMB=memory, annotation=notes)

I specified edit in VirtualDeviceSpec.Operation, however it didn't help me. This code is definitely for creating a new virtual device, but all I need is to find a portgroup and specify in vm.
Thank you in advance.

Whats the error you're getting ?
get_obj(content, [vim.Network], "<IP_ADDRESS>s24v1960")
Instead, If you have the host object,  write a method something like this
def get_hosts_pg_by_name(host_obj, pg_name):
   return  [net  for net in host_obj.network if net.name == pg_name][0]

I think you need to use 'add', instead of 'edit', if you see the documentation

add	Specifies the addition of a virtual device to the configuration.

if you want use 'edit' operation,pass  vm device to nic.device ,not new VirtualVmxnet3 like this
for dev in vm.config.hardware.device:
            if isinstance(dev, vim.vm.device.VirtualEthernetCard):
                    nic.device = dev


[DOCS] Fails to add predictions to dataset using torchvision's model

URL(s) with the issue
Please provide a link to the documentation entry in question.
Description of proposal (what needs changing)
I try the code example but doesn't have the same effect.
script
import fiftyone as fo
# You must import fiftyone as fo first, otherwise there will be
# OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5md.dll already initialized.
# not sure why
import torch
import torchvision

from PIL import Image
import torchvision.transforms.functional as func

dataset = fo.zoo.load_zoo_dataset(
    "coco-2017",
    split="validation",
    dataset_name="evaluate-detections-tutorial",
    label_types=["detections", "segmentations"],
    classes=["cat", "dog"],
    max_samples=50,
    shuffle=False,
)
dataset.persistent = True

# Run the model on GPU if it is available
device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")

model = torchvision.models.get_model('fasterrcnn_resnet50_fpn')
model.to(device)
model.eval()

classes = dataset.default_classes

# Add predictions to samples
with fo.ProgressBar() as pb:
    for sample in pb(dataset):
        # Load image
        image = Image.open(sample.filepath)
        image = func.to_tensor(image).to(device)
        c, h, w = image.shape

        # Perform inference
        preds = model([image])[0]
        labels = preds["labels"].cpu().detach().numpy()
        scores = preds["scores"].cpu().detach().numpy()
        boxes = preds["boxes"].cpu().detach().numpy()

        # Convert detections to FiftyOne format
        detections = []
        for label, score, box in zip(labels, scores, boxes):
            # Convert to [top-left-x, top-left-y, width, height]
            # in relative coordinates in [0, 1] x [0, 1]
            x1, y1, x2, y2 = box
            rel_box = [x1 / w, y1 / h, (x2 - x1) / w, (y2 - y1) / h]

            detections.append(
                fo.Detection(
                    label=classes[label],
                    bounding_box=rel_box,
                    confidence=score
                )
            )

        # Save predictions to dataset
        sample["predictions"] = fo.Detections(detections=detections)
        sample.save()

session = fo.launch_app(dataset)

log
Downloading split 'validation' to 'C:\Users\a4781\fiftyone\coco-2017\validation' if necessary
Found annotations at 'C:\Users\a4781\fiftyone\coco-2017\raw\instances_val2017.json'
Sufficient images already downloaded
Existing download of split 'validation' is sufficient
Loading 'coco-2017' split 'validation'
 100% |██████████████████████████████████████████████████████████████████████████████████████████████████████| 50/50 [504.9ms elapsed, 0s remaining, 99.1 samples/s]
Dataset 'evaluate-detections-tutorial' created
 100% |██████████████████████████████████████████████████████████████████████████████████████████████████████| 50/50 [1.7m elapsed, 0s remaining, 0.5 samples/s]
App launched. Point your web browser to http://localhost:5151

My results

You can see the labels 'predictions' has 0 objects.
You can see this fails in preds = model([image])[0]
In [23]: image
Out[23]:
tensor([[[0.6667, 0.6784, 0.6863,  ..., 0.2706, 0.2667, 0.2745],
         [0.6745, 0.6902, 0.6941,  ..., 0.2706, 0.2824, 0.2784],
         [0.6863, 0.6941, 0.6980,  ..., 0.2745, 0.2706, 0.2784],
         ...,
         [0.7373, 0.7176, 0.7569,  ..., 0.7294, 0.7294, 0.7333],
         [0.7294, 0.7333, 0.7294,  ..., 0.7765, 0.7647, 0.7294],
         [0.7294, 0.7333, 0.7294,  ..., 0.5059, 0.4941, 0.4196]],

        [[0.5333, 0.5569, 0.5647,  ..., 0.2980, 0.2980, 0.2784],
         [0.5529, 0.5686, 0.5725,  ..., 0.3020, 0.3137, 0.2941],
         [0.5647, 0.5725, 0.5765,  ..., 0.3059, 0.3020, 0.2941],
         ...,
         [0.7412, 0.7176, 0.7333,  ..., 0.6157, 0.6157, 0.6118],
         [0.7176, 0.7216, 0.7176,  ..., 0.5255, 0.4706, 0.3451],
         [0.7176, 0.7216, 0.7176,  ..., 0.2353, 0.2235, 0.1608]],

        [[0.2863, 0.3020, 0.3098,  ..., 0.1647, 0.1529, 0.1451],
         [0.3020, 0.3137, 0.3176,  ..., 0.1569, 0.1686, 0.1569],
         [0.3098, 0.3176, 0.3137,  ..., 0.1529, 0.1569, 0.1569],
         ...,
         [0.6157, 0.5843, 0.6000,  ..., 0.6000, 0.6000, 0.6039],
         [0.5961, 0.6000, 0.5961,  ..., 0.5255, 0.4863, 0.3961],
         [0.5882, 0.5922, 0.5961,  ..., 0.2471, 0.2353, 0.1765]]])

In [24]: model([image])
Out[24]:
[{'boxes': tensor([], size=(0, 4), grad_fn=<StackBackward0>),
  'labels': tensor([], dtype=torch.int64),
  'scores': tensor([], grad_fn=<IndexBackward0>)}]

Willingness to contribute
The FiftyOne Community encourages documentation contributions. Would you or another member of your organization be willing to contribute a fix for this documentation issue to the FiftyOne codebase?

[ ] Yes. I can contribute a documentation fix independently
[x] Yes. I would be willing to contribute a documentation fix with guidance from the FiftyOne community
[ ] No. I cannot contribute a documentation fix at this time

Follow-up:
I found out the reason if I use
model = torchvision.models.get_model('fasterrcnn_resnet50_fpn')
Then I will fail, but if I use
model = torchvision.models.detection.fasterrcnn_resnet50_fpn(pretrained=True)
Then I will succeed, I am curious about the reason why that two commands will have different effects?


Broker OOM when the bookie is slowly to respond and  AQ is smaller than WQ

Describe the bug
When there has a bookie is slowly to respond the add entry request, and the AQ is smaller than WQ, broker will OOM.
To Reproduce

Change the bookkeeper server code to make the add request to delay some times to handle
Build the bookkeeper code and replace the version in Pulsar
Set the managedLedgerDefaultWriteQuorum bigger than managedLedgerDefaultAckQuorum in the broker.conf
Setup the cluster
Produce message with pulsar-perf
See the broker OOM

Expected behavior
Broker should not OOM
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

macOS 12.1

Additional context
Broker version: master
BookKeeper version: branch-4.14 latest
Ensemble: 2, AQ: 1, WQ:2
broker logs:
2022-03-25T12:29:35,600+0800 [pulsar-io-4-3] INFO  com.scurrilous.circe.checksum.Crc32cIntChecksum - SSE4.2 CRC32C provider initialized
2022-03-25T12:29:35,684+0800 [pulsar-io-4-1] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x8611e44b, L:/<IP_ADDRESS>:50153 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-2] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x3e9bfafd, L:/<IP_ADDRESS>:50150 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,685+0800 [pulsar-io-4-3] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x9cc7b134, L:/<IP_ADDRESS>:50157 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-21] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-9] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x5d909697, L:/<IP_ADDRESS>:50162 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,685+0800 [pulsar-io-4-19] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xb9b91a40, L:/<IP_ADDRESS>:50158 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,685+0800 [pulsar-io-4-13] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xf9a8b922, L:/<IP_ADDRESS>:50165 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-10] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xcc74cde3, L:/<IP_ADDRESS>:50164 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,686+0800 [pulsar-io-4-24] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x9e0b4117, L:/<IP_ADDRESS>:50156 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-7] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xfe1340cf, L:/<IP_ADDRESS>:50155 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,684+0800 [pulsar-io-4-15] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x042ab445, L:/<IP_ADDRESS>:50161 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,686+0800 [pulsar-io-4-17] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x835f7112, L:/<IP_ADDRESS>:50154 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,685+0800 [pulsar-io-4-16] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x3f7eeb8a, L:/<IP_ADDRESS>:50147 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,687+0800 [pulsar-io-4-3] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x9cc7b134, L:/<IP_ADDRESS>:50157 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-17] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x835f7112, L:/<IP_ADDRESS>:50154 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-16] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x3f7eeb8a, L:/<IP_ADDRESS>:50147 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-4] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x2ee9ef18, L:/<IP_ADDRESS>:50159 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,687+0800 [pulsar-io-4-7] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xfe1340cf, L:/<IP_ADDRESS>:50155 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,685+0800 [pulsar-io-4-12] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x04f86f55, L:/<IP_ADDRESS>:50169 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,687+0800 [pulsar-io-4-4] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x2ee9ef18, L:/<IP_ADDRESS>:50159 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-15] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x042ab445, L:/<IP_ADDRESS>:50161 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-10] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xcc74cde3, L:/<IP_ADDRESS>:50164 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,684+0800 [pulsar-io-4-6] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xd81f675b, L:/<IP_ADDRESS>:50168 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,687+0800 [pulsar-io-4-11] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xb1bfb710, L:/<IP_ADDRESS>:50148 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,688+0800 [pulsar-io-4-2] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x3e9bfafd, L:/<IP_ADDRESS>:50150 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,688+0800 [pulsar-io-4-6] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xd81f675b, L:/<IP_ADDRESS>:50168 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-5] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x6659642b, L:/<IP_ADDRESS>:50167 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,688+0800 [pulsar-io-4-9] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x5d909697, L:/<IP_ADDRESS>:50162 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,688+0800 [pulsar-io-4-23] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x4640bd95, L:/<IP_ADDRESS>:50151 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,688+0800 [pulsar-io-4-23] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x4640bd95, L:/<IP_ADDRESS>:50151 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-24] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x9e0b4117, L:/<IP_ADDRESS>:50156 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,689+0800 [pulsar-io-4-1] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x8611e44b, L:/<IP_ADDRESS>:50153 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-18] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0x155b4478, L:/<IP_ADDRESS>:50166 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,689+0800 [pulsar-io-4-18] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x155b4478, L:/<IP_ADDRESS>:50166 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,689+0800 [pulsar-io-4-7] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x8c527e39, L:/<IP_ADDRESS>:50175 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,685+0800 [pulsar-io-4-8] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xeacf4e8e, L:/<IP_ADDRESS>:50170 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,689+0800 [pulsar-io-4-7] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x8c527e39, L:/<IP_ADDRESS>:50175 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,689+0800 [pulsar-io-4-6] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x6af6cc28, L:/<IP_ADDRESS>:50176 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,690+0800 [pulsar-io-4-6] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x6af6cc28, L:/<IP_ADDRESS>:50176 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,690+0800 [pulsar-io-4-8] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xeacf4e8e, L:/<IP_ADDRESS>:50170 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,690+0800 [pulsar-io-4-8] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0xb5917759, L:/<IP_ADDRESS>:50172 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,687+0800 [pulsar-io-4-13] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xf9a8b922, L:/<IP_ADDRESS>:50165 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,687+0800 [pulsar-io-4-12] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x04f86f55, L:/<IP_ADDRESS>:50169 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,691+0800 [pulsar-io-4-10] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x09c34093, L:/<IP_ADDRESS>:50173 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,686+0800 [pulsar-io-4-22] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0xde543d90, L:/<IP_ADDRESS>:50149 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,691+0800 [pulsar-io-4-10] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x09c34093, L:/<IP_ADDRESS>:50173 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,691+0800 [pulsar-io-4-22] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xde543d90, L:/<IP_ADDRESS>:50149 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,690+0800 [pulsar-io-4-8] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xb5917759, L:/<IP_ADDRESS>:50172 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,691+0800 [pulsar-io-4-12] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0xfc4f4711, L:/<IP_ADDRESS>:50177 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,692+0800 [pulsar-io-4-12] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xfc4f4711, L:/<IP_ADDRESS>:50177 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,689+0800 [pulsar-io-4-9] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0xbd3c79ca, L:/<IP_ADDRESS>:50174 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,688+0800 [pulsar-io-4-14] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xc40c5fba, L:/<IP_ADDRESS>:50160 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,692+0800 [pulsar-io-4-14] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xc40c5fba, L:/<IP_ADDRESS>:50160 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,692+0800 [pulsar-io-4-9] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xbd3c79ca, L:/<IP_ADDRESS>:50174 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,688+0800 [pulsar-io-4-19] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xb9b91a40, L:/<IP_ADDRESS>:50158 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,688+0800 [pulsar-io-4-20] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3182 [id: 0xfbb35d39, L:/<IP_ADDRESS>:50163 - R:/<IP_ADDRESS>:3182]
2022-03-25T12:29:35,688+0800 [pulsar-io-4-11] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xb1bfb710, L:/<IP_ADDRESS>:50148 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,694+0800 [pulsar-io-4-20] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xfbb35d39, L:/<IP_ADDRESS>:50163 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,695+0800 [pulsar-io-4-11] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x518a2724, L:/<IP_ADDRESS>:50171 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,695+0800 [pulsar-io-4-11] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x518a2724, L:/<IP_ADDRESS>:50171 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,697+0800 [pulsar-io-4-5] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x6659642b, L:/<IP_ADDRESS>:50167 - R:/<IP_ADDRESS>:3182] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,697+0800 [pulsar-io-4-21] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:35,764+0800 [pulsar-io-4-5] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Successfully connected to bookie: <IP_ADDRESS>:3181 [id: 0x60410eac, L:/<IP_ADDRESS>:50178 - R:/<IP_ADDRESS>:3181]
2022-03-25T12:29:35,764+0800 [pulsar-io-4-5] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - connection [id: 0x60410eac, L:/<IP_ADDRESS>:50178 - R:/<IP_ADDRESS>:3181] authenticated as BookKeeperPrincipal{ANONYMOUS}
2022-03-25T12:29:46,587+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Writing local data to metadata store because maximum change 13.203266263008118% exceeded threshold 10%; time since last report written is 14.999 seconds
2022-03-25T12:29:46,593+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Acquired resource lock on /loadbalance/brokers/<IP_ADDRESS>:8080
2022-03-25T12:30:01,587+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Writing local data to metadata store because maximum change 12.288329005241394% exceeded threshold 10%; time since last report written is 14.999 seconds
2022-03-25T12:30:01,604+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Acquired resource lock on /loadbalance/brokers/<IP_ADDRESS>:8080
2022-03-25T12:30:06,531+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 583 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:06,538+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to find 1 bookies : excludeBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], allBookies [<Bookie:<IP_ADDRESS>:3181>, <Bookie:<IP_ADDRESS>:3182>].
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to choose a bookie: excluded [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], fallback to choose bookie randomly from the cluster.
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to find 1 bookies : excludeBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], allBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>].
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to find 1 bookies : excludeBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], allBookies [<Bookie:<IP_ADDRESS>:3181>, <Bookie:<IP_ADDRESS>:3182>].
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to choose a bookie: excluded [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], fallback to choose bookie randomly from the cluster.
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl - Failed to find 1 bookies : excludeBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>], allBookies [<Bookie:<IP_ADDRESS>:3182>, <Bookie:<IP_ADDRESS>:3181>].
2022-03-25T12:30:06,539+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.MetadataUpdateLoop - UpdateLoop(ledgerId=0,loopId=38f2cbec) Exception updating
org.apache.bookkeeper.client.BKException$BKNotEnoughBookiesException: Not enough non-faulty bookies available
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectRandomInternal(RackawareEnsemblePlacementPolicyImpl.java:780) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectRandom(RackawareEnsemblePlacementPolicyImpl.java:698) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectFromNetworkLocation(RackawareEnsemblePlacementPolicyImpl.java:587) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.selectFromNetworkLocation(RackawareEnsemblePlacementPolicy.java:206) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectFromNetworkLocation(RackawareEnsemblePlacementPolicyImpl.java:547) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.selectFromNetworkLocation(RackawareEnsemblePlacementPolicy.java:227) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.replaceBookie(RackawareEnsemblePlacementPolicyImpl.java:475) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.replaceBookie(RackawareEnsemblePlacementPolicy.java:120) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.BookieWatcherImpl.replaceBookie(BookieWatcherImpl.java:334) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.EnsembleUtils.replaceBookiesInEnsemble(EnsembleUtils.java:71) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.lambda$ensembleChangeLoop$2(LedgerHandle.java:1935) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.MetadataUpdateLoop.writeLoop(MetadataUpdateLoop.java:134) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.MetadataUpdateLoop.run(MetadataUpdateLoop.java:123) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.ensembleChangeLoop(LedgerHandle.java:1954) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.handleBookieFailure(LedgerHandle.java:1903) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.maybeHandleDelayedWriteBookieFailure(LedgerHandle.java:1860) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.PendingAddOp.safeRun(PendingAddOp.java:271) [org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.common.util.SafeRunnable.run(SafeRunnable.java:36) [org.apache.bookkeeper-bookkeeper-common-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
2022-03-25T12:30:06,547+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] WARN  org.apache.bookkeeper.client.LedgerHandle - [EnsembleChange(ledger:0, change-id:0000000001)][attempt:1] Exception changing ensemble
org.apache.bookkeeper.client.BKException$BKNotEnoughBookiesException: Not enough non-faulty bookies available
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectRandomInternal(RackawareEnsemblePlacementPolicyImpl.java:780) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectRandom(RackawareEnsemblePlacementPolicyImpl.java:698) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectFromNetworkLocation(RackawareEnsemblePlacementPolicyImpl.java:587) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.selectFromNetworkLocation(RackawareEnsemblePlacementPolicy.java:206) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.selectFromNetworkLocation(RackawareEnsemblePlacementPolicyImpl.java:547) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.selectFromNetworkLocation(RackawareEnsemblePlacementPolicy.java:227) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicyImpl.replaceBookie(RackawareEnsemblePlacementPolicyImpl.java:475) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.RackawareEnsemblePlacementPolicy.replaceBookie(RackawareEnsemblePlacementPolicy.java:120) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.BookieWatcherImpl.replaceBookie(BookieWatcherImpl.java:334) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.EnsembleUtils.replaceBookiesInEnsemble(EnsembleUtils.java:71) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.lambda$ensembleChangeLoop$2(LedgerHandle.java:1935) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.MetadataUpdateLoop.writeLoop(MetadataUpdateLoop.java:134) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.MetadataUpdateLoop.run(MetadataUpdateLoop.java:123) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.ensembleChangeLoop(LedgerHandle.java:1954) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.handleBookieFailure(LedgerHandle.java:1903) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.LedgerHandle.maybeHandleDelayedWriteBookieFailure(LedgerHandle.java:1860) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.client.PendingAddOp.safeRun(PendingAddOp.java:271) ~[org.apache.bookkeeper-bookkeeper-server-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.common.util.SafeRunnable.run(SafeRunnable.java:36) ~[org.apache.bookkeeper-bookkeeper-common-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
2022-03-25T12:30:06,548+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.LedgerHandle - Closing ledger 0 due to NotEnoughBookiesException: Not enough non-faulty bookies available
2022-03-25T12:30:06,550+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20459
2022-03-25T12:30:06,551+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20460
2022-03-25T12:30:06,551+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20461
2022-03-25T12:30:06,551+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20462
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20463
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20464
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20465
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20466
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20467
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20468
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20469
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20470
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20471
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20472
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20473
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20474
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-6-0] INFO  org.apache.bookkeeper.mledger.impl.ManagedLedgerImpl - [public/default/persistent/example] Creating a new ledger
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20475
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20476
2022-03-25T12:30:06,552+0800 [BookKeeperClientWorker-OrderedExecutor-0-0] ERROR org.apache.bookkeeper.client.PendingAddOp - Write of ledger entry to quorum failed: L0 E20477
2022-03-25T12:30:06,567+0800 [BookKeeperClientWorker-OrderedExecutor-6-0] INFO  org.apache.bookkeeper.mledger.impl.ManagedLedgerImpl - [public/default/persistent/example] Creating ledger, metadata: {component=[109, 97, 110, 97, 103, 101, 100, 45, 108, 101, 100, 103, 101, 114], pulsar/managed-ledger=[112, 117, 98, 108, 105, 99, 47, 100, 101, 102, 97, 117, 108, 116, 47, 112, 101, 114, 115, 105, 115, 116, 101, 110, 116, 47, 101, 120, 97, 109, 112, 108, 101], application=[112, 117, 108, 115, 97, 114]} - metadata ops timeout : 60 seconds
2022-03-25T12:30:06,568+0800 [BookKeeperClientWorker-OrderedExecutor-6-0] WARN  org.apache.bookkeeper.client.BookieWatcherImpl - New ensemble: [<IP_ADDRESS>:3182, <IP_ADDRESS>:3181] is not adhering to Placement Policy. quarantinedBookies: []
2022-03-25T12:30:06,578+0800 [main-EventThread] INFO  org.apache.bookkeeper.client.LedgerCreateOp - Ensemble: [<IP_ADDRESS>:3182, <IP_ADDRESS>:3181] for ledger: 1
2022-03-25T12:30:06,578+0800 [main-EventThread] INFO  org.apache.bookkeeper.mledger.impl.ManagedLedgerImpl - [public/default/persistent/example] Created new ledger 1
2022-03-25T12:30:07,531+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 687 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:08,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 690 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:09,530+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 666 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:10,530+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 663 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:11,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 701 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:11,586+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Writing local data to metadata store because maximum change 12.5% exceeded threshold 10%; time since last report written is 9.998 seconds
2022-03-25T12:30:11,593+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Acquired resource lock on /loadbalance/brokers/<IP_ADDRESS>:8080
2022-03-25T12:30:12,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 604 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:13,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 643 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:14,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 673 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:15,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 638 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:16,530+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 633 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:16,586+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Writing local data to metadata store because maximum change 12.5% exceeded threshold 10%; time since last report written is 5.0 seconds
2022-03-25T12:30:16,634+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Acquired resource lock on /loadbalance/brokers/<IP_ADDRESS>:8080
2022-03-25T12:30:17,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 632 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:18,530+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 636 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:19,530+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 638 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:20,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 635 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:21,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 638 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:22,529+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 635 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:23,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 636 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:23,547+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] WARN  org.apache.bookkeeper.client.BookieWatcherImpl - Bookie <IP_ADDRESS>:3181 has been quarantined because of read/write errors.
2022-03-25T12:30:24,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 635 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:25,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 636 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:26,429+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Only 1 broker available: no load shedding will be performed
2022-03-25T12:30:26,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 633 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:26,587+0800 [pulsar-load-manager-1-1] INFO  org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl - Writing local data to metadata store because maximum change Infinity% exceeded threshold 10%; time since last report written is 10.001 seconds
2022-03-25T12:30:26,756+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Acquired resource lock on /loadbalance/brokers/<IP_ADDRESS>:8080
2022-03-25T12:30:26,760+0800 [pulsar-modular-load-manager-28-1] INFO  org.apache.pulsar.broker.loadbalance.BundleSplitStrategy - The count of topics on the bundle public/default/0xa0000000_0xb0000000 is less than 2，skip split!
2022-03-25T12:30:27,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 605 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:28,528+0800 [BookKeeperClientScheduler-OrderedScheduler-0-0] INFO  org.apache.bookkeeper.proto.PerChannelBookieClient - Timed-out 655 operations to channel [id: 0xc663bf3d, L:/<IP_ADDRESS>:50152 - R:/<IP_ADDRESS>:3181] for <IP_ADDRESS>:3181
2022-03-25T12:30:29,087+0800 [pulsar-io-4-3] ERROR org.apache.pulsar.PulsarBrokerStarter - -- Shutting down - Received OOM exception: failed to allocate 16777216 byte(s) of direct memory (used: 268435456, max: 268435456)
io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 268435456, max: 268435456)
	at io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:802) ~[io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:731) ~[io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:648) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:623) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:202) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:186) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:136) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:126) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:394) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) ~[io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at org.apache.bookkeeper.common.allocator.impl.ByteBufAllocatorImpl.newDirectBuffer(ByteBufAllocatorImpl.java:163) [org.apache.bookkeeper-bookkeeper-common-allocator-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at org.apache.bookkeeper.common.allocator.impl.ByteBufAllocatorImpl.newDirectBuffer(ByteBufAllocatorImpl.java:157) [org.apache.bookkeeper-bookkeeper-common-allocator-4.14.3-SNAPSHOT.jar:4.14.3-SNAPSHOT]
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) [io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) [io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:140) [io.netty-netty-buffer-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:120) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:150) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) [io.netty-netty-transport-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) [io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [io.netty-netty-common-4.1.74.Final.jar:4.1.74.Final]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
2022-03-25T12:30:29,111+0800 [pulsar-io-4-3] INFO  org.apache.pulsar.broker.PulsarService - Invoking Pulsar service immediate shutdown
2022-03-25T12:30:29,118+0800 [metadata-store-9-1] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Lock on resource /namespace/pulsar/test/<IP_ADDRESS>:8080/0x00000000_0xffffffff was invalidated
2022-03-25T12:30:29,119+0800 [metadata-store-9-1] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Lock on resource /namespace/public/default/0xa0000000_0xb0000000 was invalidated
2022-03-25T12:30:29,120+0800 [metadata-store-9-1] WARN  org.apache.pulsar.metadata.coordination.impl.LeaderElectionImpl - Leadership released for /loadbalance/leader
2022-03-25T12:30:29,121+0800 [metadata-store-9-1] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Lock on resource /loadbalance/brokers/<IP_ADDRESS>:8080 was invalidated
2022-03-25T12:30:29,122+0800 [metadata-store-9-1] INFO  org.apache.pulsar.metadata.coordination.impl.ResourceLockImpl - Lock on resource /namespace/pulsar/<IP_ADDRESS>:8080/0x00000000_0xffffffff was invalidated
2022-03-25T12:30:29,226+0800 [main-EventThread] INFO  org.apache.pulsar.metadata.impl.ZKSessionWatcher - Got ZK session watch event: WatchedEvent state:Closed type:None path:null

log file:
oom.log

https://github.com/apache/bookkeeper/pull/3139 Here has a PR proposal to resolve this issue.

@zymap This seems to be related to #10439 .

Yes

@zymap hi! We also encountered the same problem. The broker has an OutOfDirectMemoryError, but after I set the waitTimeoutOnBackpressureMs=50 parameter, I have seen that the backpressure has taken effect, but the broker has an OutOfMemoryError: Java heap space. What other parameters can control the memory usage?

@keyboardbobo That also needs some bookie side configurations. Such as maxAddsInProgressLimit: "10", maxReadsInProgressLimit: "10", waitTimeoutOnResponseBackpressureMs: "5".
By default, the pulsar uses a v2 request to the bookie, there haven't the request limits on the server side. We apply this through this PR https://github.com/apache/bookkeeper/pull/3324.
We are releasing the bookie 4.15.1 which includes that.

@zymap We only have three brokers and three bookies in the test environment. After the back pressure is turned on, a lot of BKNotEnoughBookiesException: Not enough non-faulty bookies available and more Spent 8 ms waiting for 3 writable channels appear from time to time (I think this is can be used as debug log), is there any way to avoid it?

If you configured the write quorum as 3, I'd suggest you increase the bookie node to 4 or more. After configuring the back pressure, it should be normal to have that exception. Because once a bookie is slow, the bookie will not available for writing and it needs to find another bookie to write.
If you only have 3 bookies. I'd suggest you to configure the WQ and AQ as 2 to avoid this.

@zymap Is there a resolution for this issue? Would it be possible to add documentation to Pulsar for describing the way to tune Pulsar and Bookkeeper properly?

If a bookie is slow, if enough bookies are available, will the broker automatically write to another bookie? It sounds like the workaround is to have (total bookies + N) > WQ
where N depends on the load.


EC_POINT_hex2point incorrectly decodes the point at infinity

EC_POINT_hex2point incorrectly decodes the point at infinity, which is encoded as the hexstring 00. This is because hex2point calls oct2point after converting 00 into a BIGNUM and calling BN_bn2bin on this bignum, which outputs 0 bytes whereas the decoder is expecting exactly 1 0 byte in this case.

So, I digged a bit into this.
This behavior has been there since 1.0.2.
It appears EC_POINT_hex2point() and its callee EC_POINT_bn2point() have not supported decoding 00 as the point at infinity, even though EC_POINT_point2hex() might encode the point at infinity as 00.
It is unclear to me how to proceed.
Maybe the fix is actually throwing an error already on EC_POINT_point2hex() if operating on the point at infinity.
Fixing the decoding step might open more security risks than it is worth it.
Ping @mattcaswell and @bbbrumley for feedback.

Check 2.3.3 here, with the caveat this is only one standard's opinion.
(I personally feel "import" or "export" of INF point is meaningless -- at the engineering view, it is a low level implementation detail.)

Check 2.3.3 here, with the caveat this is only one standard's opinion.
(I personally feel "import" or "export" of INF point is meaningless -- at the engineering view, it is a low level implementation detail.)

So it seems we are conforming to 2.3.3 when encoding, but not to 2.3.4 when decoding.

I will open a PR to address the behavior in 1.1.1 and master, but it does not fit in the cop of 1.0.2 and 1.1.0

See #10329 for a fix


Add espaloma compatibility

Fixes #
Changes made in this Pull Request:

PR Checklist

[ ] Tests?
[ ] Docs?
[ ] CHANGELOG updated?
[ ] Issue raised/referenced?

Codecov Report

Merging #91 (9e02602) into main (ffce46e) will decrease coverage by 1.11%.
The diff coverage is n/a.

Additional details and impacted files

I'm not sure this needs explicit testing. Closing.


Poor parallelism in BLOOM indexing stage with Hudi 0.12.3

Describe the problem you faced
Hello, Recently we migrated our datasets from Hudi 0.8 to Hudi 0.12.3 and started experiencing slowness in indexing stage in some tables during upserts.
After looking into spark steps, we found out that there was one particular stage where Hudi set a very low value parallelism for a indexing stage (stage 32 in the screenshoot) and ended up causing long duration and shuffle spill which further slowdown the stage. We set hoodie.bloom.index.parallelism=2000 however, it doesn't seem to affect the parallelism of that particular stage.
In Hudi 0.8, Hudi used to use a much larger value for parallelism for this stage, and we never experienced slowness in indexing stage.
Can you please help us understand if there is any Hudi configuration we should use to increase the parallelism for the stage?
We also tried setting hoodie.copyonwrite.record.size.estimate to a very small value and found that it seems help forcing Hudi to use a larger parallelism for indexing, but the effect it's very inconsistent as we still see small values being set for the stage across upsert jobs.
Environment Description
Hudi version : 0.12.3
Spark version : 3.1.3
Hive version : 3.1.3
Hadoop version : 3.3.3
Storage (HDFS/S3/GCS..) : S3
Running on Docker? (yes/no) : no
EMR: 6.10.0
Additional context
Hudi configs
hoodie.metadata.enable: true
hoodie.metadata.validate: true
hoodie.cleaner.commits.retained: 72
hoodie.keep.min.commits: 100
hoodie.keep.max.commits: 150
hoodie.datasource.write.payload.class: org.apache.hudi.common.model.DefaultHoodieRecordPayload
hoodie.index.type: BLOOM
hoodie.bloom.index.parallelism: 2000
hoodie.copyonwrite.record.size.estimate: 1
hoodie.metadata.enable: true
hoodie.datasource.write.table.type: COPY_ON_WRITE
hoodie.insert.shuffle.parallelism: 1500
hoodie.datasource.write.operation: upsert
hoodie.datasource.hive_sync.partition_extractor_class: org.apache.hudi.hive.MultiPartKeysValueExtractor
hoodie.datasource.write.keygenerator.class: org.apache.hudi.keygen.ComplexKeyGenerator

torvalds.dev is analyzing the ticket

The user is facing an issue with Apache Hudi version 0.12.3 where they are experiencing slowness in the indexing stage during upserts. They have noticed that Hudi is setting a very low value for parallelism for a particular indexing stage, which is causing a long duration and shuffle spill, further slowing down the stage. They have tried setting the hoodie.bloom.index.parallelism to 2000, but it doesn't seem to affect the parallelism of that stage. They have also tried setting hoodie.copyonwrite.record.size.estimate to a very small value, which seems to force Hudi to use a larger parallelism for indexing, but the effect is inconsistent.
The user is asking for help in understanding if there is any Hudi configuration they should use to increase the parallelism for the stage.
The user has provided their Hudi configuration and a code snippet. The code snippet seems to be a part of a test case for Hudi, where they are setting up a Hudi configuration, creating a Hudi table, and performing some operations on it.
Plan:

Understand the user's Hudi configuration and the provided code snippet.
Research on the issue related to parallelism in Hudi's BLOOM indexing stage.
Provide a solution or workaround to the user's problem.


Add text outline / shadow / glow

Currently using the widget without any background cuz I don't like the colors available, but the white text clashes with the brighter colors on my wallpaper.
Is it possible to let the user select an outline or a glow effect for the text, and select ita color separately? That would allow users to customize it more, for example white glow for dark text, black glow (shadow) for white text and pink glow for quote gurus 😄 etc.

Version 3.0.6, when released next, moves the colour selection from lists to a chooser. So lots of choice.
Can you explain the "glow" effect? Maybe give me an example. It might be possible to change how the text looks (beyond what's already available), but widget's are kind of limited in what you can do. So being a bit more specific would help me :-)

I'd imagine it to work much like the effects in Photoshop:
Here it is currently without any glow/stroke:

With black stroke:

With black glow:

With funky fresh colors and glow:

(Kinda hastily made mockups, but they do convey the idea lol)

It looks like adding some sort of shadow is possible - see: https://stackoverflow.com/questions/3297437/shadow-effect-for-a-text-in-android
I'll play around with something and see what I can come up with.

@jameshnsears I see. That's unfortunate, but I think at least a "drop shadow" version would be nice to have, to separate bright text from bright backgrounds. For reference look at the mockups I posted above.
Thanks for taking the time to investigate and work on this! ❤

Hi - I have released 3.0.7 - which contains a solution to this issue.
It will take a few days for it to appear in Google Play & F-Droid.
Let me know if you spot a problem and I'll re-open this issue.


Create istio.deps to activate dependency update

This file defines a list of repos as dependencies of the parent repo. It only concerns about repos under the istio project umbrella. Automated dependency update uses this file to learn what dependencies are and pull their latest versions to compare with what has been used on master of parent repo. It might be useful to take a look at https://github.com/istio/test-infra/blob/master/toolbox/util/dependency.go
What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

None

PTAL
One question I have is that in https://github.com/istio/pilot/blob/master/test/integration/driver.go#L57 we have SHAs from auth and mixer, but it says update manually at the moment. Do we want to auto update those as well?

No need to update those. Mixer needs to be replaced with a fake mixer but don't have hands to do that. CA is rather simple at that SHA.
Where's the script that does the update? Can that script be hosted here, so we know what's happening?

The script to update dependency is at https://github.com/istio/test-infra/blob/master/toolbox/deps_update/main.go
I think hosting it here is not ideal.

It creates duplication. Any changes to the original script must also be copied over to all duplicates.
The script uses a lot of shared utility in test-infra such as GitHub API client, which means they have to be copied over as well.
The script is meant to be generic. It can update the dependencies of any repo under the istio umbrella by simply changing the flag.

Would be nice to have backreference to the script. Maybe make it YAML so we can put comments into it?

I include a comment with reference to the update script in the latest commit. Since we have enabled auto dependency update on other repos (each has a istio.deps file like this one), it is hard to switch to yaml at the moment. If you strongly believe yaml is perferred in this case, I encourage that you file an github issue with the label asks-to-engprod.
An example PR created by the script to update dependencies of pilot can be found here
https://github.com/chxchx/pilot/pull/5/files

@chxchx: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/pilot-presubmit.sh
d1825bd72ac63e07d26c840e3be6193c8706cfa9
link
/test pilot-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ldemailly This helps to get proxy into pilot as requested. Would love to have your input.

you could add some comments but
/lgtm
we need to get the bot in place asap so let's get this in


Make it faster

Currently the code uses a loop that divides the size by 1K until size becomes less than 1k to detrmine the suffix.
Perhaps this could be re-written to use count_zeros for performance.
This needs to be profiled though, to avoid a naive mis-optimization.

I could be wrong, but looking at your code, it could be 1024 or 1000 so you can't use a simple count_zeros, trailing_zeros, or size check. So you could right the code specialized for one size over the other or you could if you wanted to treat divider as if it was 1000 to use the other "optimizations". But this too wouldn't be great as you'd still need a branch to see if you guessed right as.
What you are really looking for mathematically is a (size.ln()  / divider.ln()).floor() . This would tell you exactly how many times you would want to divide. However this is probably more expensive than the while loop itself. I wouldn't be sure without testing it.
Just my two cents.

This is a playground link just showing off what I was talking about with the math. https://is.gd/65Zjaa . Once again though this would have to be bench marked to see if it actually makes sense. We are talking possible branch prediction misses on the while loop vs obviously more calculations with two ln and a pow call.

Good catch! Only had 1024 in mind when I made a note of this. IIRC it's implementation dependent how ln(x) will be calculated, but this would almost certainly be a misoptimization. I may revisit this someday, but I'll close for now.
Cheers!

My pleasure, enjoy the weekend.


PyPi Org, Releases

The "VLSIR family" has a half dozen or so interdependent PyPi packages:

vlsir - the schema bindings
vlsirtools - most of the useful code
hdl21
each of the open PDKs: ASAP7, Sky, GF
a few others which are internal or deprecated

We would like to enable some more contributors to help publish them. Especially as the maintainers focuses have shifted elsewhere. I think we want to:

Create a pypi.org organization
Move all this stuff into it
Grant one or more new folks publishing access

I have a request in for a vlsir org on pypi. They apparently review & approve each one.
@joamatab - how are you guys doing this for GdsFactory?
And do you have any other team members you'd like to have weigh in?

Hi Dan,
For the GDSFactory organization, we use a PyPI organization secret to handle publishing to PyPI seamlessly.
I’d be happy to assist with any improvements or updates you’re planning for VLSIR.
Here’s the GitHub Action workflow we currently use for our releases:
Release Workflow
I've cc'ed Niko who might also be interested in helping out
@nikosavola


Page loads blank (plain black/white screen) in Desktop App

[x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
[x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
[x] I have read contributing guidelines.

Summary
Page loads blank (plain black/white screen) in Desktop App
Steps to reproduce
When dragging the server name (top left corner of the screen) towards the center, as shown in the image, the server name and URL are displayed. And once the element is released onto the mattermost screen, it opens to a blank screen, forcing a user to reload the Desktop App so that they can view the page again.
This issue appears in Ubuntu 16.04, Windows 7 & 10.
It probably appears in all mattermost versions. I have checked in  3.9, 4.2, 4.4.
Expected behavior
When dragging the server name, server name appears 'file:///C:/User ... index.html?/index=0#'
Perhaps the problem is that url appears as 'file:///C:/User ... index.html?/index=0#' instead  server url(pre-release.mattermost.com).
Observed behavior
Click mouse on the server UI:

argp: my server name
'file:///C:/User ... index.html?/index=0#': The server url assigned by the Meromost desktop app.
Drag and Drop serverUI to mattermost screen ( randomly appear ):

When the link is dropped into the contents region, an internal <webview> loads it. So the dropping should be denied on webviews.
For now, please avoid to drag&drop tabs.

@yuya-oc Reporter came back about the most recent issue posted by @amyblais above. #750 didn't resolve it.
https://pre-release.mattermost.com/core/pl/5zr4asf1m3r7bxq56nm7j47ozo
Yes that is exactly the issue.

Please let me know if you need a testing device we can schedule time for you.  I am also willing to test any nightly builds you may have.

For some strange reason alt-tab works just fine ( i believe that it is because the screen HAS to be redrawn due to the graphic it shows). I have read that this is an issue with the version of electron that is used to draw your iFrame and that a newer version of it fixes it.

Please let me know what i can do to help

The reported mentioned it might be related to an Electron issue fixed with this PR: https://github.com/electron/libchromiumcontent/pull/503

@jasonblais Okay. I think https://github.com/electron/libchromiumcontent/pull/503 is related to the problem, too. I had misunderstood because DWM is disabled in the report and it's related to rendering. Would you create another issue to track that?

Sure thing. Have asked @amyblais to help create it. Closing this issue as the original report should be resolved with #752

New issue here: https://github.com/mattermost/desktop/issues/753

i m getting page like this!!!!

what went wrong?

@bdrmdrsylp Hey, looks like GitHub was having issues, can you try reload the page (CTRL/CMD+R or via the "Reload this page" icon next to the URL bar?

If you're still having issues, I recommend contacting GitHub support (https://github.com/contact) as it doesn't appear to be an issue with Mattermost :)


It is recommended to put binary in the user directory

Below is err message.

Do you intend to make it a nonroot image? Would be nice if you can attach a link to the best practice as I'd love to learn more.

can you help to update https://github.com/Phala-Network/khala-docker/blob/main/dockerfile.d/start_node.sh#L46 to reflect the change?

can you help to update https://github.com/Phala-Network/khala-docker/blob/main/dockerfile.d/start_node.sh#L46 to reflect the change?
I prefer to do it. I will submit PR again after modify the shell and test ok


Fix sound source onended handling

When pause is called the onEndedObservable is being fired, but it should only be fired when stop is called.
This change fixes the issue.
Reported on forum here: https://forum.babylonjs.com/t/pausing-and-playing-an-audio-with-offset-restarts-it-from-the-beginning-instead-of-the-current-position/36668/23

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/13472/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13472/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13472/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/13472/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/13472/merge
https://gui.babylonjs.com/?snapshot=refs/pull/13472/merge
https://nme.babylonjs.com/?snapshot=refs/pull/13472/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/13472/merge#BCU1XR#0

I understand this is a bug fix, and it LGTM (after addressing Seb's comment). I don't really get the event flow here and why it is working this way (why set the onended to an empty function?...), but this is probably part of the audio system revamp.

This is the essence of the reported bug. Before I changed it, the pause function would disconnect onended so the observers would not receive it since it should only be fired when the sound is stopped, not when it's paused.