Infinite loop in rich_text_label.cpp (ERROR: _process_line: Index line = 0 is out of bounds)

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

Godot version:
Godot 3.2.2.beta1
OS/device including version:
MacOSX 10.14.6 (18G95)
Issue description:
Today all day I'm working on fixing pvrtc and twice my godot did hung up with this errors:
   At: scene/gui/rich_text_label.cpp:170.
ERROR: _process_line: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
   At: scene/gui/rich_text_label.cpp:170.
ERROR: _process_line: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
   At: scene/gui/rich_text_label.cpp:170.
ERROR: _process_line: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
   At: scene/gui/rich_text_label.cpp:170.
ERROR: _process_line: Index line = 0 is out of bounds (l.offset_caches.size() = 0).

It repeats in infinite cycle and godot interface is frozen. I can not reproduce it when I want to. But two times it happened.
Steps to reproduce:
Minimal reproduction project:

This code is weird. line is guaranteed to be 0 here, so the check whether line is between 0 and the size should be simplified to just a check for if the size is 0. I don't know why it would be 0, though.

I haven't looked majorly into this, but I think that the caching system and this check might be what's returning garbage line size values as well. So I think this is possibly related to #18722. @DrMoriarty I haven't had a chance to reproduce this myself and can't find a way to reproduce it. If someone else can try getting a gdb trace on this, that'd be very useful.
For  the record, as someone who has worked on this class within the last year (or two I suppose), the problem this class currently has is that the codeflow is hard to parse because of a combination of extensive macro-use and arguably too many vaguely named variables. It's kind of on my todo to go back to this class and clean it up to make it easier to work with, but I never really find the time.

line is guaranteed to be 0 here, so the check whether line is between 0 and the size should be simplified to just a check for if the size is 0.

@aaronfranke Indeed. I think there's a very high likelihood that these checks were actually intended for the macro define on line 216 and were but in the wrong place probably because the macro text is greyed out.

Not sure if it's related but this issue consistently happens since I tried adding multi-threading to my addon. I'll see if I can produce a minimal reproduction project but the code is so convoluted I'm having a hard time tracking down this issue.

Just wanted to confirm that I'm now getting this same error, every single time I push a build to my Android phone for debugging, and it seems to have started as soon as I started using ResourceInteractiveLoader to switch scenes. Removing that part of the code doesn't seem to have stopped this issue from happening every time I run the debugger, but disabling "Small Deploy with Network FS" seems to work. This also seems to only affect Android as far as I can tell, and not when I run a debug build on Windows 10.

I'm working on a C++ module and I'm having the same experience as @HungryProton. I do procedural generation from a thread and this happens sometimes when I use print_line(). The reproduction rate seems arbitrary.

@Eoin-ONeill-Yokai I have a trace

GDB bt

#0  0x00007ffff76ef4bf in write () from /lib64/libc.so.6
#1  0x00007ffff767f4cd in _IO_file_write@@GLIBC_2.2.5 () from /lib64/libc.so.6
#2  0x00007ffff767e826 in new_do_write () from /lib64/libc.so.6
#3  0x00007ffff767fbfe in __GI__IO_file_xsputn () from /lib64/libc.so.6
#4  0x00007ffff766b6b1 in buffered_vfprintf () from /lib64/libc.so.6
#5  0x00007ffff7668654 in __vfprintf_internal () from /lib64/libc.so.6
#6  0x0000000006e549cd in StdLogger::logv (this=0x77d6750, p_format=0x1b21d10 "%sERROR:%s %s\n",
    p_list=0x7fffffffab70, p_err=true) at core/io/logger.cpp:230
#7  0x0000000006e53901 in Logger::logf_error (this=0x77d6750, p_format=0x1b21d10 "%sERROR:%s %s\n")
    at core/io/logger.cpp:100
#8  0x00000000048b0543 in UnixTerminalLogger::log_error (this=0x77d6750,
    p_function=0x1b453da "_process_line", p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
    p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
    p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at drivers/unix/os_unix.cpp:582
#9  0x0000000006e54c59 in CompositeLogger::log_error (this=0x77d6790,
    p_function=0x1b453da "_process_line", p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
    p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
    p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at core/io/logger.cpp:264
#10 0x0000000006cac54a in OS::print_error (this=0x7fffffffd5e8, p_function=0x1b453da "_process_line",
    p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
    p_code=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
    p_rationale=0x1b8389b "", p_type=Logger::ERR_ERROR) at core/os/os.cpp:120
#11 0x0000000006ab6e57 in _err_print_error (p_function=0x1b453da "_process_line",
    p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176,
    p_error=0x3a4cb630 "Index line = 0 is out of bounds (l.offset_caches.size() = 0).",
    p_message=0x1b8389b "", p_type=ERR_HANDLER_ERROR) at core/error_macros.cpp:81
#12 0x0000000006ab7513 in _err_print_index_error (p_function=0x1b453da "_process_line",
    p_file=0x1b453e8 "scene/gui/rich_text_label.cpp", p_line=176, p_index=0, p_size=0,
    p_index_str=0x1a8d3f2 "line", p_size_str=0x1a18d15 "l.offset_caches.size()", p_message=0x1b8389b "",
    fatal=false) at core/error_macros.cpp:110
#13 0x0000000005977a06 in RichTextLabel::_process_line (this=0xe7d23d0, p_frame=0xe7d2a90, p_ofs=...,
    y=@0x7fffffffc91c: 172, p_width=1333, p_line=470075, p_mode=RichTextLabel::PROCESS_DRAW,
    p_base_font=..., p_base_color=..., p_font_color_shadow=..., p_shadow_as_outline=false,
    shadow_ofs=..., p_click_pos=..., r_click_item=0x0, r_click_char=0x0, r_outside=0x0,
    p_char_count=18487) at scene/gui/rich_text_label.cpp:176
#14 0x00000000059818fe in RichTextLabel::_notification (this=0xe7d23d0, p_what=30)
    at scene/gui/rich_text_label.cpp:1039
#15 0x000000000599626b in RichTextLabel::_notificationv (this=0xe7d23d0, p_notification=30,
    p_reversed=false) at scene/gui/rich_text_label.h:39
#16 0x0000000006b45a4b in Object::notification (this=0xe7d23d0, p_notification=30, p_reversed=false)
    at core/object.cpp:914
#17 0x00000000056d24d8 in CanvasItem::_update_callback (this=0xe7d23d0) at scene/main/canvas_item.cpp:452
#18 0x00000000056e7764 in MethodBind0::call (this=0x8acf450, p_object=0xe7d23d0, p_args=0x0,
    p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:147
#19 0x0000000006b48f6a in Object::call (this=0xe7d23d0, p_method=..., p_args=0x0, p_argcount=0,
    r_error=...) at core/object.cpp:904
#20 0x0000000006a86323 in Callable::call (this=0x7fffe9e31020, p_arguments=0x0, p_argcount=0,
    r_return_value=..., r_call_error=...) at core/callable.cpp:52
#21 0x0000000006b3d043 in MessageQueue::_call_function (this=0x78d1990, p_callable=...,
    p_args=0x7fffe9e31038, p_argcount=0, p_show_error=false) at core/message_queue.cpp:253
#22 0x0000000006b3d392 in MessageQueue::flush (this=0x78d1990) at core/message_queue.cpp:303
#23 0x000000000575cba5 in SceneTree::idle (this=0x911c180, p_time=0.020833334)
    at scene/main/scene_tree.cpp:460
#24 0x00000000035535b5 in Main::iteration () at main/main.cpp:2190
#25 0x00000000035168e6 in OS_LinuxBSD::run (this=0x7fffffffd5e8) at platform/linuxbsd/os_linuxbsd.cpp:259
#26 0x0000000003514276 in main (argc=4, argv=0x7fffffffdac8) at platform/linuxbsd/godot_linuxbsd.cpp:56

I am using threads, and it's causing this issue to me.
I don't understand why it works sometimes, shouldn't we always update GUI from the main thread?
as a workaround, instead of updating the control immediately (richtext to store console/terminal logs in my case), I am storing the list of strings I want to add to my log.
I am actually wondering how it works sometimes anyway, I don't think we can update the GUI from a thread other than the main, it seems like there's something that handles such situations in Godot?
before
        private Node _console;
        private Node Console
        {
            get
            {
                if (_console == null)
                    _console = GetNode("/root/Console");
                return _console;
            }
        }
        public void WriteLine(string text)
        {
            Console.Call("writeLine", text);
        }

        public void Write(string text)
        {
            Console.Call("write", text);
        }

after
        private Node _console;
        private Queue<string> _logLines = new Queue<string>();
        private Queue<string> _logs = new Queue<string>();

        private Node Console
        {
            get
            {
                if (_console == null)
                    _console = GetNode("/root/Console");
                return _console;
            }
        }

        public void WriteLine(string text)
        {
            _logLines.Enqueue(text);
        }

        public void Write(string text)
        {
            _logs.Enqueue(text);
        }

        public override void _Process(float delta)
        {
            base._Process(delta);
            while(_logs.Count > 0)
                Console.Call("write", _logs.Dequeue());
            while(_logLines.Count > 0)
                Console.Call("writeLine", _logLines.Dequeue());
        }

This just started happening to me quite often in 3.2 branch at commit 49b3750b3671e6c0c3edd0ca4d41df85593ff26f.
I'm not explicitly using threads in GDScript land -- only the intrinsic threads the engine itself uses, and the threaded LSP server.
Here's the backtrace I was able to catch:
#0  RichTextLabel::_process_line (this=0xe6a7810, p_frame=0xe6a7f90, p_ofs=..., y=@0x7fffffffcec4: 0, p_width=-8, p_line=0, p_mode=RichTextLabel::PROCESS_DRAW, p_base_font=..., p_base_color=..., p_font_color_shadow=..., p_shadow_as_outline=false, shadow_ofs=..., p_click_pos=..., r_click_item=0x0, r_click_char=0x0, r_outside=0x0, p_char_count=0) at scene/gui/rich_text_label.cpp:170
#1  0x000000000320a8c4 in RichTextLabel::_notification (this=0xe6a7810, p_what=30) at scene/gui/rich_text_label.cpp:1025
#2  0x0000000003230d1d in RichTextLabel::_notificationv (this=0xe6a7810, p_notification=30, p_reversed=false) at scene/gui/rich_text_label.h:39
#3  0x000000000512b898 in Object::notification (this=0xe6a7810, p_notification=30, p_reversed=false) at core/object.cpp:932
#4  0x00000000037e4a5e in CanvasItem::_update_callback (this=0xe6a7810) at scene/2d/canvas_item.cpp:459
#5  0x000000000058820a in MethodBind0::call (this=0xb370ed0, p_object=0xe6a7810, p_args=0x0, p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:59
#6  0x000000000512b62f in Object::call (this=0xe6a7810, p_method=..., p_args=0x0, p_argcount=0, r_error=...) at core/object.cpp:922
#7  0x0000000005114680 in MessageQueue::_call_function (this=0x9edfb40, p_target=0xe6a7810, p_func=..., p_args=0x7ffff692b5f0, p_argcount=0, p_show_error=false) at core/message_queue.cpp:250
#8  0x0000000005114aa7 in MessageQueue::flush (this=0x9edfb40) at core/message_queue.cpp:297
#9  0x0000000002f0f555 in SceneTree::iteration (this=0xb840020, p_time=0.0166666675) at scene/main/scene_tree.cpp:483
#10 0x00000000004ae8e8 in Main::iteration () at main/main.cpp:2084
#11 0x0000000000453b75 in OS_X11::run (this=0x7fffffffd7f0) at platform/x11/os_x11.cpp:3233
#12 0x00000000004387c7 in main (argc=2, argv=0x7fffffffe008) at platform/x11/godot_x11.cpp:56

@Rubonnek Well, since there's currently a planned refactor (as seen in RichTextLabel issues tracker), I think that this would likely be addressed by that refactor.
Out of curiosity, do you happen to have a scene configuration where this is quickly reproducible?

@Eoin-ONeill-Yokai Unfortunately I wasn't able to reproduce the issue consistently. It just happened to me five times in a row in the same project, but suddenly it stopped happening. I spent a couple of hours trying to reproduce it but to no avail.

I can add that it always happened when one of my i3-wm windows was full screen,  the project was running with a RichTextLabel node in it, and all three windows (i.e. the Editor, the running project, and my external text editor) were in the same workspace. My external editor connected to the LSP server covered the Editor as well as the project I was running, as I was debugging the code.

I'm not using threads, for me if you enable verbose debugging and output a bunch into the godot console on re-importing an FBX file which is particularly big and click the scrollbar it will sometimes trigger the problem, but only if the log is super long.
maybe someone could make a print_verbose somewhere with like 100,000 lines into the console to debug the issue it might reveal the problem

Related (likely duplicate, but both have useful debugging info) to #17815. See also #43705 which is about this issue happening when printing from threads.

I was on v3.3.3.stable.official [b973f997f], running with -verbose on the editor and testing the game. I was messing with a script, and decided to run a test scene, after I pressed run scene, I noticed that the debug print panel it was still loading some texture resources from my project, the game started on the scene running, everything okay, then suddenly it frooze, upon going to the print there was the error:
ERROR: _process_line: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
   At: scene/gui/rich_text_label.cpp:170

Looped to infinity until I closed Godot. I had this bug twice in a row, I was going to update to a newer version to test if it still happenned, but it suddenly stopped giving the error. I don't know what triggered, and the thing is, I never had that bug for a long time, and I did not executed any major changes aside from running with -verbose, and I also didn't edited anything related to richtextlabels in a loong while, so I cannot pinpoint the error. Also found 2 closed issues with the same problem.
https://github.com/godotengine/godot/issues/29491
https://github.com/godotengine/godot/issues/16072

I've ran into this using 3.4 stable. Where the editor will indefinitely freeze up while continuously outputting:
Index line = 0 is out of bounds (l.offset_caches.size() = 0).
It happens with my plugin when threading and printing is involved.
Removing the print statements stopped the editor from outputting this error and freezing.

I've had the editor periodically crash when I switch back to it after making changes in VSCode. It freezes for about 30 seconds then finally crashes. It's rare, so I don't have any idea how to reproduce it. It's been happening for several weeks. It wasn't until today that I ran the editor from the command line and saw this error message. I couldn't see whether there was anything before it in the logs because it prints it out a LOT. Weirdly, I'm not using RichTextLabel anywhere in the code, so I take it this is related to an editor UI widget thing rather than something in the scene. Also, most recently, this happened when I made changes to scripts that are not used at all in the scene that I have open, so not sure what would've caused it.

I'm seeing this on 3.3.4 stable with scripts that run in tool mode - if I spawn a thread to parse an OBJ file and call print() from the parsing code, the editor will lock up and proceed to fill system RAM with error spam until killed. Evidently the offending RichTextLabel is the debug console itself in this case.
Removing the print statements prevents the issue, but also makes debugging that code next to impossible without creating a non-threaded sandbox in which to test it.

I'm seeing this on 3.3.4 stable with scripts that run in tool mode - if I spawn a thread to parse an OBJ file and call print() from the parsing code, the editor will lock up and proceed to fill my system's RAM with error spam until killed. Evidently the offending RichTextLabel is the debug console itself in this case.
Removing the print statements prevents the issue, but also makes debugging that code next to impossible without creating a non-threaded sandbox in which to test it.

If this is reproducible with a stack trace, could you supply a minimum testing environment? It might help with debugging.

Not sure if it's related but this issue consistently happens since I tried adding multi-threading to my addon. I'll see if I can produce a minimal reproduction project but the code is so convoluted I'm having a hard time tracking down this issue.

Same here. Doing a terrain sculpting addon. I thought it went away, but it's back now :'(

Same happening to me. Using v3.4.3 to build an addon with multi-threads and this was popping up a lot.
I did something horrible just to be able to use print to debug:
func fakeprint(msg):
    print(msg)

Then inside a method that runs on a different thread I do:
func whatever():
    call_deferred("fakeprint", ["print me"])

I am still getting this in 3.5.rc and might be able to provide additional information.
This error will not occur if the output console is minimized so that it's no longer visible.
I have also been able to get the following stack log that leads to Index line = 0 is out of bounds (l.offset_caches.size() = 0). being printed
godot.windows.opt.tools.64.exe!write_text_ansi_nolock(const int fh, const char * const buffer, const unsigned int buffer_size) Line 415	C++
godot.windows.opt.tools.64.exe!_write_nolock(int fh, const void * buffer, unsigned int buffer_size) Line 679	C++
godot.windows.opt.tools.64.exe!_write(int fh, const void * buffer, unsigned int size) Line 64	C++
godot.windows.opt.tools.64.exe!write_buffer_nolock<char>(const char c, const __crt_stdio_stream stream) Line 95	C++
[Inline Frame] godot.windows.opt.tools.64.exe!common_flush_and_write_nolock(const int) Line 174	C++
godot.windows.opt.tools.64.exe!__acrt_stdio_flush_and_write_narrow_nolock(int c, _iobuf * stream) Line 190	C++
godot.windows.opt.tools.64.exe!_fputwc_nolock(wchar_t c, _iobuf * public_stream) Line 64	C++
[Inline Frame] godot.windows.opt.tools.64.exe!__crt_char_traits<wchar_t>::puttc_nolock(const wchar_t &) Line 124	C++
[Inline Frame] godot.windows.opt.tools.64.exe!__crt_stdio_output::stream_output_adapter<wchar_t>::write_character_without_count_update(const wchar_t c) Line 166	C++
godot.windows.opt.tools.64.exe!__crt_stdio_output::output_adapter_common<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>>::write_string_impl(const wchar_t * const string, const int length, int * const count_written, __crt_deferred_errno_cache & status) Line 86	C++
[Inline Frame] godot.windows.opt.tools.64.exe!__crt_stdio_output::stream_output_adapter<wchar_t>::write_string(const wchar_t * const string, const int length, int * const count_written, __crt_deferred_errno_cache &) Line 182	C++
godot.windows.opt.tools.64.exe!__crt_stdio_output::output_processor<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>,__crt_stdio_output::standard_base<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>>>::write_stored_string_tchar(wchar_t __formal) Line 2735	C++
godot.windows.opt.tools.64.exe!__crt_stdio_output::output_processor<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>,__crt_stdio_output::standard_base<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>>>::state_case_type() Line 2150	C++
godot.windows.opt.tools.64.exe!__crt_stdio_output::output_processor<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>,__crt_stdio_output::standard_base<wchar_t,__crt_stdio_output::stream_output_adapter<wchar_t>>>::process() Line 1699	C++
godot.windows.opt.tools.64.exe!common_vfprintf::__l2::<lambda>() Line 49	C++
godot.windows.opt.tools.64.exe!__crt_seh_guarded_call<int>::operator()<<lambda_676bd5779251ec186b530f0a904b4b35>,int <lambda>(void) &,<lambda_10027885da78ada7fb00668d7e2e96b5>>(__acrt_lock_stream_and_call::__l2::<lambda_676bd5779251ec186b530f0a904b4b35> && setup, common_vfprintf::__l2::int <lambda>(void) & action, __acrt_lock_stream_and_call::__l2::<lambda_10027885da78ada7fb00668d7e2e96b5> && cleanup) Line 204	C++
[Inline Frame] godot.windows.opt.tools.64.exe!__acrt_lock_stream_and_call(_iobuf * const) Line 252	C++
[Inline Frame] godot.windows.opt.tools.64.exe!common_vfprintf(const unsigned __int64 options, _iobuf * const stream, const wchar_t * const format, __crt_locale_pointers * const locale, char * const arglist) Line 37	C++
godot.windows.opt.tools.64.exe!__stdio_common_vfwprintf(unsigned __int64 options, _iobuf * stream, const wchar_t * format, __crt_locale_pointers * locale, char * arglist) Line 73	C++
[External Code]
godot.windows.opt.tools.64.exe!WindowsTerminalLogger::logv(const char * p_format, char * p_list, bool p_err) Line 63	C++
godot.windows.opt.tools.64.exe!Logger::logf_error(const char * p_format, ...) Line 122	C++
godot.windows.opt.tools.64.exe!WindowsTerminalLogger::log_error(const char * p_function, const char * p_file, int p_line, const char * p_code, const char * p_rationale, Logger::ErrorType p_type) Line 133	C++
godot.windows.opt.tools.64.exe!CompositeLogger::log_error(const char * p_function, const char * p_file, int p_line, const char * p_code, const char * p_rationale, Logger::ErrorType p_type) Line 284	C++
godot.windows.opt.tools.64.exe!_err_print_error(const char * p_function, const char * p_file, int p_line, const char * p_error, const char * p_message, ErrorHandlerType p_type) Line 79	C++
godot.windows.opt.tools.64.exe!_err_print_index_error(const char * p_function, const char * p_file, int p_line, __int64 p_index, __int64 p_size, const char * p_index_str, const char * p_size_str, const char * p_message, bool fatal) Line 110	C++
godot.windows.opt.tools.64.exe!RichTextLabel::_process_line(RichTextLabel::ItemFrame * p_frame, const Vector2 & p_ofs, int & y, int p_width, int p_line, RichTextLabel::ProcessMode p_mode, const Ref<Font> & p_base_font, const Color & p_base_color, const Color & p_font_color_shadow, bool p_shadow_as_outline, const Vector2 & shadow_ofs, const Vector2i & p_click_pos, RichTextLabel::Item * * r_click_item, int * r_click_char, bool * r_outside, int p_char_count) Line 930	C++
godot.windows.opt.tools.64.exe!RichTextLabel::_notification(int p_what) Line 1072	C++
godot.windows.opt.tools.64.exe!RichTextLabel::_notificationv(int p_notification, bool p_reversed) Line 38	C++
godot.windows.opt.tools.64.exe!Object::notification(int p_notification, bool p_reversed) Line 929	C++
godot.windows.opt.tools.64.exe!CanvasItem::_update_callback() Line 456	C++
godot.windows.opt.tools.64.exe!MethodBind0<CanvasItem>::call(Object * p_object, const Variant * * p_args, int p_arg_count, Variant::CallError & r_error) Line 148	C++
godot.windows.opt.tools.64.exe!Object::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 918	C++
godot.windows.opt.tools.64.exe!MessageQueue::_call_function(Object * p_target, const StringName & p_func, const Variant * p_args, int p_argcount, bool p_show_error) Line 241	C++
godot.windows.opt.tools.64.exe!MessageQueue::flush() Line 301	C++
godot.windows.opt.tools.64.exe!SceneTree::idle(float p_time) Line 605	C++
godot.windows.opt.tools.64.exe!Main::iteration() Line 2298	C++
godot.windows.opt.tools.64.exe!OS_Windows::run() Line 3506	C++
godot.windows.opt.tools.64.exe!widechar_main(int argc, wchar_t * * argv) Line 176	C++
godot.windows.opt.tools.64.exe!_main() Line 200	C++
godot.windows.opt.tools.64.exe!main(int _argc, char * * _argv) Line 210	C++

In regards to the RichTextLabel::_process_line function it will throw the error from the following line:
if (p_mode != PROCESS_CACHE) {
		ERR_FAIL_INDEX_V(line, l.offset_caches.size(), 0);
		line_ofs = l.offset_caches[line];
	}

I have created a minimal reproduction project for this issue.
In order to see the issue enable the plugin and make sure that the Godot editor output console is visible. After a few seconds it will start producing the error.
Note that if the editors output is not visible the error won't occur but the editor will soon freeze once it's visible.
The error is produced by calling this function within a thread created by the plugin:
func printOut():
	while(true):
		print("print out ------------------------------------")
		OS.delay_msec(1)

Note that decreasing the delay will cause the output text to become increasingly more garbled
richTextError.zip

I've hit what looks to be this problem in 3.5. After having my program lock up pretty consistently (it fails when I hit an "export" button in my project ~90% of the time) and not being able to see the error, I went back to 3.4.4 and saw the symptoms described above.

I wonder if using call_deffered instead of call in the MessageQueue would help here. I can't help but wonder if there's some kind of String-based data race happening here where the memory gets garbled before it reaches the rich text. It might be worth a test in the next few days.

I am running into the same issue.
My minimal reproduction project does not contain any scenes, scripts, exporting, or anything with threads. It is three nearly empty resource files and a project.godot
Godot version
Tested on both Mac and Linux
Reproduced with

3.4.4-stable
3.5-stable
3.5-stable custom build (tag: 3.5-stable)
Mac: scons platform=osx arch=arm64 target=release_debug
Linux: scons platform=x11 arch=x64 target=release_debug
3.5.1-rc1

Unable to reproduce with

3.5-stable custom build (tag: 3.5-stable)
Mac: scons platform=osx arch=arm64 target=debug
Linux: scons platform=x11 arch=x64 target=debug
4.0rc14

System information
Mac M1
Ubuntu 20.04.1
Steps to reproduce

Extract the zip file somewhere, and cd into it

Clear the cache and launch the editor from the command line

Mac
  rm -rf ~/Library/Caches/Godot
  /path/to/Godot -v --path . --editor

Linux
  rm -rf ~/.cache/godot
  /path/to/Godot_v3.5-stable_x11.64 -v --path . --editor

In the editor, click on Output to view the output.  You should see something similar to this.
 Godot Engine v3.5.stable.official (c) 2007-2022 Juan Linietsky, Ariel Manzur & Godot Contributors.
 Loaded builtin certs
 --- GDScript language server started ---
 EditorSettings: Save OK!
 Loading resource: res://dynamicfont.tres
 Loading resource: res://dynamicfontdata1.tres
 Loading resource: res://dynamicfontdata2.tres
 Loading resource: res://dynamicfontdata1.tres
 Loading resource: res://dynamicfontdata2.tres

The Output window must remain open to reproduce the bug, so leave it open.

Right click on dynamicfont.tres, then choose "Duplicate" and give it a different name.

You may have to do this several times (usually less than ten times, if it'll repro).
On Mac I've had the best success; where duplicating dynamicfont.tres just once reproduces the problem.
On Linux I've had less luck, where I'd have to duplicate dynamicfont.tres (or any of the duplicates) 5 to 10 times
(and even quit the editor, clear the cache, and restart the editor) before the bug occurs.

Watch the editor freeze.

This error message is spammed in the terminal
 ERROR: Index line = 0 is out of bounds (l.offset_caches.size() = 0).
    at: _process_line (scene/gui/rich_text_label.cpp:168)

Video (from Mac, but similar is seen on Linux)
https://user-images.githubusercontent.com/109488824/189353599-4b3b4373-d20c-471e-9cc7-1c54aeadcdbe.mp4
Minimal reproduction project
DynamicFontInfiniteLoop.zip
Notes

As mentioned earlier, the Output window must be opened to reproduce the bug.
I suspect that Output is implemented with a rich_text_label.

When you duplicate a resource, and the bug does not occur, you must see something like this in the Output
  Duplicating res://dynamicfont.tres -> res://a.tres
  FileSystem: calling rescan.
  Loading resource: res://a.tres
  Loading resource: res://dynamicfontdata1.tres
  Loading resource: res://dynamicfontdata2.tres

If you only see
  Duplicating res://dynamicfont.tres -> res://a.tres
  FileSystem: calling rescan.

Then the bug has no chance of happening. To see the bug, Godot must "reload" the resource when you duplicate it.
To make this happen, exit the editor, clear the cache, and restart the editor
Alternatively, name the duplicate resource something unique (in my case, b.tres hasn't been used in any editor session yet)

The reproduction steps clear the Godot cache.  This is to ensure duplicated resources are "reloaded", even if Godot has loaded that file in a previous editor session.  For example, if a previous editing session loaded a.tres, then Godot will not reload it unless if the cache was cleared before launching the editor.

-v (--verbose) makes it reproducible 100% of the time.
In this minimal project, I wasn't successful in reproducing the failure without -v.
In my actual project, the failure seemed random when -v was omitted since it only happened when Godot would also load the duplicate resource. It is obvious when Godot loads the duplicate resource because I had code that printed text when _init() was called.

The DynamicFont resource (dynamicfont.tres) must load two or more ExtResources.  I couldn't reproduce the problem with SubResources nor with only one ExtResource.

This minimal project points to two ttf fonts that do not exist.  The problem occurs regardless if they point to real ttfs or not.

I'm unable to reproduce this on master when building for x64, but it's pretty consistently cropping up when building and running the x32 version on Windows.

I'm unable to reproduce this on master when building for x64, but it's pretty consistently cropping up when building and running the x32 version on Windows.

Just to be clear, do you mean that it's reproducible for a Win32 x86_32 build of the master branch? So far the results were only about 3.x and RichTextLabel has been significantly refactored in master, so I guess we assumed it fixed in 4.0. CC @bruvzg @Paulb23

I'm unable to reproduce this on master when building for x64, but it's pretty consistently cropping up when building and running the x32 version on Windows.

Just to be clear, do you mean that it's reproducible for a Win32 x86_32 build of the master branch? So far the results were only about 3.x and RichTextLabel has been significantly refactored in master, so I guess we assumed it fixed in 4.0. CC @bruvzg @Paulb23

@akien-mga I'll give it more testing later, but I seemed to be getting a pretty consistent crash on x86_32 build on my 64bit Windows when using master when trying one of the user's provided test project -- though the importance of this is debatable.  I'll provide the backtrace when I give it more testing.
I'm not entirely sure this is a RichTextLabel  / Godot problem or perhaps just a problem with the users test file as a whole (doing something weird, causing a data race which results in undefined behavior) though so I'll also look through the test project more.

@akien-mga Ah, the error on master is actually caused by improper cleanliness of threads in DataPlusProgram's example project. In their example, the thread should probably be stored as a member of the plugin so that it doesn't go out of scope and get (eventually) cleaned up.
So it's worth noting that particular example project might not be an accurate test.

could you clarify what would be the correct way to handle this as I have moved the scope of the thread but I still see the same issues:
tool
extends EditorPlugin
var thread = Thread.new()

func printOut():
	while(true):
		print("print out ------------------------------------")
		OS.delay_msec(1)

func _ready():
	thread.start(self, "printOut")

could you clarify what would be the correct way to handle this as I have moved the scope of the thread but I still see the same issues:

Is this on 4.0 (master branch / alpha) or is this a 3.x specific issue?
I think the confusion right now is around which versions have had this issue. Judging by the gdscript issue, this still looks like a 3.X related issue. I'll double back and check 3.X to see if I can find a solution that doesn't involve bundling all the changes made in 4.X. As far as I could tell, this issue is now gone in 4.X.
And yeah that should be correct now.

Yes it's 3.x and still produces the same errors as a mentioned previously.


Etcd removal annotation not removed on cluster reset / restore

If the etcd member removal annotation is used to prepare a node for deletion from the cluster, and the annotation is set at the time an etcd snapshot is taken, the node can attempt to re-remove itself from the cluster after a reset or restore.
This occurred for a customer:

Rancher was used to scale the etcd+control-plane nodes down from 3 to 1.
The scale-down failed for some unknown reason (possibly due to known issues with CAPI resize)
The user restored one of the servers from a VM snapshot, and arbitrarily picked server 2 to restore.
The user performed an etcd-snapshot restore on server 2.
The snapshot restore was successful, but logs show the server trying to remove itself from the etcd cluster immediately upon startup. The removal was rejected by etcd, as it would leave the cluster with no members. The node was otherwise functional.
The user then added another server to the cluster.
As soon as the additional server joined the etcd cluster, the etcd member removal succeeded, making the just-joined server the only cluster member.
The entire cluster got very confused, with the first server stuck in a restart loop and the other server partially functional.

Live troubleshooting confirmed that the remove annotation came back every time the restore was performed, confirming that it was marked for removal in the snapshot itself.
We should ensure that the member removal annotations are cleared from all Node objects following a cluster reset / restore. This  should probably be done early in the startup of the etcd member management controller.

##Environment Details
VERSION=v1.28.2+k3s1
COMMIT=79b44cee29c7a0ee10e7f972d68f0e7ee586b25c
Infrastructure

[X] Cloud

Node(s) CPU architecture, OS, and version:
Linux 5.14.21-150500.53-default x86_64 GNU/Linux
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"

Config.yaml:
server: https://<IP_ADDRESS>:6443
write-kubeconfig-mode: 644
debug: true
token: YOUR_TOKEN_HERE
profile: cis-1.23
selinux: true

Reproduction

$ curl https://get.k3s.io --output install-"k3s".sh
$ sudo chmod +x install-"k3s".sh
$ sudo groupadd --system etcd && sudo useradd -s /sbin/nologin --system -g etcd etcd
$ sudo modprobe ip_vs_rr
$ sudo modprobe ip_vs_wrr
$ sudo modprobe ip_vs_sh
$ sudo printf "on_oovm.panic_on_oom=0 \nvm.overcommit_memory=1 \nkernel.panic=10 \nkernel.panic_ps=1 \nkernel.panic_on_oops=1 \n" > ~/60-rke2-cis.conf or ~/90-kubelet.conf
$ sudo cp 60-rke2-cis.conf /etc/sysctl.d/ or 90-kubelet.conf
$ sudo systemctl restart systemd-sysctl
$ sudo INSTALL_K3S_VERSION=v1.28.2+k3s1 INSTALL_K3S_EXEC=server ./install-k3s.sh
$ set_kubefig //export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
$ k annotate node ip-1-1-2-168 etcd.k3s.cattle.io/remove=true
$ sudo k3s etcd-snapshot save

Annotation is still present when performing the deletion by manually annotating the node before taking the snapshot, restoring, and checking the annotations on the nodes present.
...
...
...
INFO[0017] Managed etcd cluster membership has been reset, restart without --cluster-reset flag now.


V0.13.0

Codecov Report

Merging #16 (827111f) into main (bdb817e) will decrease coverage by 0.17%.
The diff coverage is 93.87%.

@@            Coverage Diff             @@
##             main      #16      +/-   ##
==========================================
- Coverage   96.82%   96.65%   -0.18%
==========================================
  Files          66       66
  Lines        5324     5465     +141
==========================================
+ Hits         5155     5282     +127
- Misses        169      183      +14

Flag
Coverage Δ

unittests
96.65% <93.87%> (-0.18%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

spacepackets/ccsds/spacepacket.py
96.13% <ø> (ø)

tests/ccsds/test_space_packet.py
100.00% <ø> (ø)

tests/ecss/test_ecss.py
100.00% <ø> (ø)

spacepackets/util.py
90.60% <60.00%> (-0.97%)
:arrow_down:

spacepackets/ccsds/time.py
86.17% <82.55%> (-2.96%)
:arrow_down:

spacepackets/ecss/tc.py
89.74% <83.33%> (-0.31%)
:arrow_down:

spacepackets/ecss/tm.py
94.61% <89.65%> (-1.59%)
:arrow_down:

spacepackets/ecss/pus_17_test.py
100.00% <100.00%> (ø)

spacepackets/ecss/pus_1_verification.py
90.50% <100.00%> (ø)

tests/ecss/test_pus_tc.py
100.00% <100.00%> (ø)

... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Token size error

Hello dear colleagues!
I use you library for sending Apple push notifications version 0.4.3 and I faced with trouble
09:45:07.113 [nioEventLoopGroup-2-1] DEBUG com.relayrides.pushy.apns.ApnsConnection - APNs gateway rejected notification with sequence number 1 from JoinyPushManager-connection-0 (INVALID_TOKEN_SIZE)

I sure that the problem is not associated with a certificates and a choice between dev or prod environments.
Can you give the answer about this situation and what i should fixed in code? I used valid token with 64 symbols that converts in byte array with size 32.
Best regards, Viachaslau Kalevich
Software Engineer
IssueTokenSize.txt

Hello!
This sounds more like a request for general support than it does like a bug report or a feature request. We generally ask people to move these kinds of questions to the Pushy mailing list because:

The mailing list has a wider audience, and you're more likely to find somebody who has experience with your particular circumstances on the mailing list.
Posting your question to the mailing list can help other people who are having the same problem.
Because there isn't a bug to fix or a feature to add, we can't reasonably solve your problem by making any kind of engineering change.

I emphasize that we'd be happy to help, but let's move this conversation to a different venue.


Fix create_parents option

Fixed Issues

None

Summary of Changes

Fix but in FileCachePrefix.get_local_path(get_parents)

Known Problems

None

Code Review Agent Run Status

Limitations and other issues: The AI Code Review Agent was unable to review this change because Bito workspace Development has reached its limit on available AI requests set by the workspace admin.Please coordinate with your workspace admin to check and adjust the overage limits set for your workspace.


blobstore.Create() is deprecated

https://cloud.google.com/appengine/docs/deprecations/files_api
This application uses blobstore.Create() and probably should switch to the new APIs before deprecation.

+1

@mjibson Can you please post a statement ("Yes" or "No" should be sufficient) whether or not you're planning to tackle this (on time)?

Yes, I plan on fixing this before the cutoff date.

Awesome, thank you! :+1:

:confetti_ball: thanks!

There is another email, Notice for Task Queue Developers on Google App Engine.

More specifically, we have determined that the above application(s) has at least one queue with a retry limit of zero. Currently, a bug causes queues with a retry limit set to zero to retry failed tasks exactly once. The upcoming 1.9.25 version of App Engine will include an update where such tasks will not be retried.

Does go read needs changes related to this too?

That's just configuration (the queue.yaml), so the only thing goread could do is change the default.
Anyway, the change / fix should not break anything in case of goread, just make it work as intended.

@vinipsmaker Nope, no necessary changes to the task queue.yaml. They are fixing a bug, but we weren't depending on the buggy behavior.


update react peer dependencies to support react v17

This PR addresses https://github.com/jungsoft/materialui-daterange-picker/issues/28 and https://github.com/jungsoft/materialui-daterange-picker/issues/34 to update react peer dependencies so that we can use this package with React 17. 🎉

Would be great if @jungrafael or any other maintainer can have a look! Thanks! 😄

hi @thealphaversion, thanks for the PR! I'll release a new version soon

hi @thealphaversion, thanks for the PR! I'll release a new version soon

Can I do anything to help? This is a dependency of my project and I am trying to avoid forking it but we need to get on React 17.

hi @thealphaversion, thanks for the PR! I'll release a new version soon

Can I do anything to help? This is a dependency of my project and I am trying to avoid forking it but we need to get on React 17.

Did you found any way to use it on React 17 without forking?


Javascript kernel missing in new C# .dib notebooks

Describe the bug
The javascript Kernel does not appear in the list of available kernels.
Steps to reproduce:

create a new notebook .dib, C#
save the notebook
close VS Code
open notebook with VS Code
the notebook is open, with one empty C# cell
try to change the cell kernel
javascript is absent from the kernel list

Please complete the following:
Which version of .NET Interactive are you using? (In a notebook, run the #!about magic command. ):
Version: 1.0.553001+f0ec3826954ea1ab829b435418328e4aa8db58e2

OS

[ ] Windows 11
[x] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[ ] Chrome
[ ] Edge
[ ] Firefox
[ ] Safari

Frontend

[ ] Jupyter Notebook
[ ] Jupyter Lab
[ ] nteract
[x] Visual Studio Code
[ ] Visual Studio Code Insiders
[ ] Visual Studio
[ ] Other (please specify)

I can repro this and while I dig into it, here's a workaround:

Run a cell with the #!javascript magic command.

JavaScript nows appears in the cell kernel picker, and is persistent after the notebook is closed and reopened.


HBASE-24265 Remove hedged rpc call support, implement the logic in MaterRegistry …

…directly

The function here is like region replica so I do not think we should implement it in the rpc framework, as the prepered way in HBase, is to implement a special RpcRetryingCaller.
Anyway MasterRegistry is a bit strange, as it is the root of the client implementation, so we can not make use of the existing rpc retrying caller, but anyway, implement the hedge logic in MasterRegistry is still easier than in the rpc framework.
And I dropped the fan out parameter. This is because that, usually we will only have 2 masters, and even if we have more, I do not think it makes much difference. So I only support two options, send the request one by one, or send them altogether at the same time.
And since now the logic is in MasterRegistry, both rpc client implementation can work with MasterRegistry.
PTAL. @saintstack @bharathv
Thanks.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 28s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 39s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 11s
master passed

+1 :green_heart:
checkstyle
2m 34s
master passed

+1 :green_heart:
spotbugs
4m 52s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 55s
the patch passed

+1 :green_heart:
checkstyle
2m 12s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
13m 30s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
5m 50s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 36s
The patch does not generate ASF License warnings.

49m 58s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 46fe4994150a 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 84f2e95dd5

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 48s
the patch passed

+1 :green_heart:
compile
1m 57s
the patch passed

+1 :green_heart:
javac
1m 57s
the patch passed

+1 :green_heart:
shadedjars
5m 12s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 26s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 38s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 35s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m  5s
hbase-client in the patch passed.

-1 :x:
unit
130m 16s
hbase-server in the patch failed.

162m  3s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c28062a52037 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 84f2e95dd5

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/testReport/

Max. process+thread count
3970 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 21s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 30s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 50s
master passed

+1 :green_heart:
compile
1m 42s
master passed

+1 :green_heart:
shadedjars
5m 26s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 18s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 44s
the patch passed

+1 :green_heart:
compile
1m 42s
the patch passed

+1 :green_heart:
javac
1m 42s
the patch passed

+1 :green_heart:
shadedjars
5m 27s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 21s
hbase-client generated 2 new + 2 unchanged - 0 fixed = 4 total (was 2)

_ Other Tests _

+1 :green_heart:
unit
1m 37s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m  7s
hbase-client in the patch passed.

-1 :x:
unit
198m 13s
hbase-server in the patch failed.

229m 42s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 0e2e489f7973 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 84f2e95dd5

Default Java
1.8.0_232

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk8-hadoop3-check/output/diff-javadoc-javadoc-hbase-client.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/testReport/

Max. process+thread count
3680 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Trying to understand the motivation for this refactor.

The function here is like region replica so I do not think we should implement it in the rpc framework, as the prepered way in HBase, is to implement a special RpcRetryingCaller.

I think hedging RPC support is a standard RPC layer thing (for ex grpc: [1]). We can probably make a case to port region replica to hedging framework in the RPC layer. Fun fact, when I first implemented this as a prototype, I had all the logic in the master registry itself and then the review comments from @apurtell and @saintstack were to push it into a layer below, which is RPC and it made sense to me.
Also, anyone who wants to implement hedging means they have to write a lot of boiler plate code around synchronizing responses from multiple RPC threads and issuing cancellations etc. It is not trivial and why would anyone want to do that all over again?
There are some issues we can fix, like the one you noted in the jira, to fix the usage of common fork join pool (I'm trying to think why I did that, I initially implemented it like a regular async code implementation, but revered it later). Let me think a little bit about why I did this and get back to you.

And I dropped the fan out parameter. This is because that, usually we will only have 2 masters, and even if we have more, I do not think it makes much difference. So I only support two options, send the request one by one, or send them altogether at the same time.

We use > 5 masters for redundancy in our critical production deployments. If we were to use this, we definitely don't want to spam every master for each of the request. -1 on removing it unless you have a strong counter argument.
[1] https://github.com/grpc/proposal/blob/master/A6-client-retries.md#hedging-policy

I think >2 masters is a common deployment pattern. Typical ZooKeeper and HDFS HA deploy requires three coordinator hosts minimum, so it makes sense to deploy 3 masters across these same hosts as well.

To be clear, I'm good on disabling a flakey test till it gets love. Doesn't mean I in favor of a purge of this hedging facility.

Things are different in HBase. HBase is a rich client, you can see the implementation of the roc retrying caller. Typically, in HBase, a rpc retrying will lead to a clearing of meta location cache and then relocating, or fetching the new masters.
For the case here, you have a test function to verify that whether the return protobuf message is valid right? In your old code, if someone returns an invalid protobuf message, the rpc framework will not consider it as incorrect and will return it to the upper layer and leads to a failure, even if other endpoints may give you the correct result. And if you implement the logic in MasterRegistry directly, you are free to wait request from other masters as well.
And implementing hedge read is not an easy work. As I mentioned on the JIRA issue, the implementation is not fully ‘async’, it just execute a blocking operation in a thread pool, and uses an anti pattern in java that execute a critical task in common pool, which may lead to unpredictable dead lock.
GRPC has the hedge read support does not mean we have to support the feature. Even if we make use of GRPC directly, as said above, I do not think we will use its hedge read feature directly. Different scenarios.

And if you guys really want to implement the hedge read support, please open a new issue for it, and implement the feature in both rpc client implementations, and make it suitable for other operations as well, not only for MasterRegistry. For example, support the read replica feature.
Now the implementation was pulled in as a side effect of MasterRegistry, and lacked of lots of features. For example, only support NettyRpcClient, do not have built in retries support, etc.
To be clear, it is not a good idea to expose a feature which may have a long term impacting when implementing another feature. Developers may accidentally use it and then it becomes a cancer of the code since it is not in a good shape at the beginning. I spent a lot of time to purge the old stale code in sync client, both in rpc implementation and the old retrying caller, especially, the big big AsyncProcess class. I do not want to do it in the future again.
Thanks.

I think >2 masters is a common deployment pattern. Typical ZooKeeper and HDFS HA deploy requires three coordinator hosts minimum, so it makes sense to deploy 3 masters across these same hosts as well.

It does not make much difference with 2 or 3 masters, if we have 10 masters then maybe it worths to implement the 'fan out limit' feature, but the code will also be harder to understand, think of a mix of the current 'sending all requests concurrently' and 'sending requests one by one'. Notice that, a blocking wait here is not allowed, so...

We use > 5 masters for redundancy in our critical production deployments. If we were to use this, we definitely don't want to spam every master for each of the request. -1 on removing it unless you have a strong counter argument.

OK, for me it is fine to add this back.  I have the confidence to implement this feature correctly.

I think hedging RPC support is a standard RPC layer thing (for ex grpc: [1]). We can probably make a case to port region replica to hedging framework in the RPC layer. Fun fact, when I first implemented this as a prototype, I had all the logic in the master registry itself and then the review comments from @apurtell and @saintstack were to push it into a layer below, which is RPC and it made sense to me.

Most code of the current rpc-client and hbase-client are written by me so I think I'm more familiar with these things in HBase. We have retries everywhere in hbase-client, but we just use the same RpcRetryingCaller if we have the same retrying logic, so the argument here that if we do not implement hedge read in rpc layer then everyone needs to implement the logic by its own does not make sense.
The problem here is the design of the client library. The ConnectionRegistry is the root of everything, we must make it available before we actually create the RpcClient which is used across all the client, so we can not make use of all the RpcRetryingCallers. But this is only a problem for the Registry implementation, not a common problem for the whole hbase client.

"hedgingPolicy": {
"maxAttempts": 4,
"hedgingDelay": "0.5s",
"nonFatalStatusCodes": [
"UNAVAILABLE",
"INTERNAL",
"ABORTED"
]
}
Back to the feature in grpc, this is the configs for the feature. Looking at the code in HBase, what do we do when there is an error? We just send the request again to the same endpoint? No! Definitely not. We need to check whether the endpoint is the correct place to go, if not, we change to another endpoint.

I think what we want in 2.3.0 is MasterRegistry, not hedge read rpc right? So my goal is to make sure MasterRegistry available first and then we start the think of the hedge read feature.
If you guys think we must have hedge read feature in the rpc framework in 2.3.0, then I will veto on releasing 2,3.0 with the current code base. Let's at least move the read replicas logic down to the rpc framework layer if we really want to do this(although I do not think this is necessary in HBase). Maybe this will spend several months...

Just realized this work was triggered by HBASE-24264. How did you narrow it down to testHedgedAsyncEcho? There is not much detail in the jira/commit. Any jstacks? Curious what was hanging in the test and if we can de-flake it.

To be honest, when I looked at the implementation of HedgedRpcChannel I just gave up on finding out the root cause as the code is not real 'async'...

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
9m 28s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 34s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  8s
master passed

+1 :green_heart:
checkstyle
2m 13s
master passed

+1 :green_heart:
spotbugs
4m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 54s
the patch passed

+1 :green_heart:
checkstyle
2m  6s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 47s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
5m 33s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 40s
The patch does not generate ASF License warnings.

54m 52s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux eca944a6f809 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6eb5cafe34

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 50s
the patch passed

+1 :green_heart:
compile
1m 56s
the patch passed

+1 :green_heart:
javac
1m 56s
the patch passed

+1 :green_heart:
shadedjars
5m  9s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 25s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m  6s
hbase-client in the patch passed.

+1 :green_heart:
unit
117m 52s
hbase-server in the patch passed.

149m  7s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ecc243600dbf 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6eb5cafe34

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/testReport/

Max. process+thread count
4724 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
9m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 34s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  6s
master passed

+1 :green_heart:
compile
1m 54s
master passed

+1 :green_heart:
shadedjars
5m 45s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 23s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 48s
the patch passed

+1 :green_heart:
compile
1m 50s
the patch passed

+1 :green_heart:
javac
1m 50s
the patch passed

+1 :green_heart:
shadedjars
5m 34s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 23s
hbase-client generated 2 new + 2 unchanged - 0 fixed = 4 total (was 2)

_ Other Tests _

+1 :green_heart:
unit
1m 29s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 12s
hbase-client in the patch passed.

+1 :green_heart:
unit
189m  6s
hbase-server in the patch passed.

230m  0s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a1e0bef62533 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6eb5cafe34

Default Java
1.8.0_232

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/artifact/yetus-jdk8-hadoop3-check/output/diff-javadoc-javadoc-hbase-client.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/testReport/

Max. process+thread count
3491 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Okay, let me first summarize your beef with the current approach, for my own understanding and for those following so that they can weigh in too. Your main concerns are as follows. I'll try to answer each one separately.

Implementation is not real async, uses a background driver thread

Lack of retries support built into the channel.

Implementation doesn't support both blocking and non-blocking RPC implementations

Read replicas was not ported to this feature, if we want to go with this approach, port read replicas too (or else you'll veto).

HBase client implementation is not like GRPC, so it may not make sense to have hedging support in HBase just because GRPC did it.

This is true. May be I was a little lazy and I missed it when I implemented. I quickly put-together what I think is the async version you are looking for. Its here #1601 if wanted to take a look.
It doesn't use a dedicated thread anymore and relies on the last failed RPC thread of a previous batch to invoke the next batch in the same thread. Just FYI, the patch is raw and could be cleaned up, I quickly put it together so that you have something to look at. Also, to add, the issue with implementing it as a channel means that we don't have flexibility of returning CompletableFutures (due to proto buf interfaces). That makes the code to look a little unstructured but I think we can back it up with comments. Let me know what you think.

I already clarified it in the design and class comments. Hedging is orthogonal to retries. You probably don't want to mix both of them. Also, the implementation adds a "Channel", and it doesn't make sense to have retries at the Channel level. That said, nothing stops us from having retries from the cilent side, just like the your code in AsyncRpcRetryingCaller...

I actually disagree with you on this. I don't see why we should support BlockingRpcClient anymore. Async client is the current Java way of doing things and it has feature parity with Blocking client implementation and is the default.  If we end up doing this for a blocking client, it is going to be ton of code (and effort) that no one uses. Do we really want to do that?

Well, I don't know how to answer this. I didn't do it because of lack of time. These set of patches were committed probably a month or two back and since then I was busy. I can attempt it but I cannot guarantee that I'll finish it in 2.3.0 time frame given my other commitments.  Also, I don't fully understand the concern here. Just because one feature was not ported to a new framework, doesn't mean we should totally get rid of it.

Of course HBase is not like GRPC. I was just trying to give an example. The analogy there was that HBase also has an abstraction of rpc stack and client implementation relying on rpc stack. So I think it makes sense to have hedging  as a feature in the rpc stack.

Well, all rpc frameworks have a dream to implement everything. But unfortunately, this is a rpc framework only for HBase, not for everyone. So there is a final judgement on whether or not implement a feature in rpc framework, is that if it introduces more complexity in code.
The motivation here is to support hedge read in MasterRegistry, and you can see the patch, "+186 -629", I just added 186 lines but removed 629 lines to just support the same function. OK there are about 100 lines of test code removed, any way, it is still about 200 vs. 500.
So I think for supporting MasterRegistry, implement it in MaterRegistry directly is much better than imlementing it in rpc. And the reason is very easy to understand, we do not need extra abstraction...
On other usage of hedged reads, the first thing is the read replica feature. If you can prove that, you can use less code to support same feature in rpc framework than RpcRetryingCaller, then I'm OK with implementing the hedged reads feature in rpc.
So my suggestion here is still, remove the hedged reads feature to not block the 2.3.0 release, and open another issue for implementing it, as it has much more long term impact than the MasterRegistry feature.
Thanks.

For your statement on BlockingRpcClient, well, I'm fine with removing it as it is outdated, which still uses the tech from the 1990s(or even 1980s?)
But I still need to say, as netty is widely used, more developers are not familiar with the word 'NIO' and 'BIO'. The 'Blocking' in its name does not mean the rpc implementation is blocking, it just means the socket is in blocking mode. In netty there is a rarely used Channel type called 'OIO', it is the same thing here. Obviously, you can use netty OIO to write async code, so in HBase you can also use the BlockingRpcClient to implement async code. As you can see that, our async hbase client can run on both NettyRpcClient and BlockingRpcClient.
Thanks.

Oh, forgot to say, in the newest patch I implemented the fan out limit feature.

On other usage of hedged reads, the first thing is the read replica feature. If you can prove that, you can use less code to support same feature in rpc framework than RpcRetryingCaller, then I'm OK with implementing the hedged reads feature in rpc.

Ok, let me read the code for read replicas. I had a brief look at it just now and I see that the timeline reads are very much intertwined with AsyncSingleRequestRpcRetryingCaller (which is common for all gets/puts/...etc). We need to separate it out for hedging gets and I think we can port it to use hedging rpc framework but I don't know about the number of lines, it may be more or less. Anyway, I don't think number of lines is always the right metric to go by.

So my suggestion here is still, remove the hedged reads feature to not block the 2.3.0 release, and open another issue for implementing it, as it has much more long term impact than the MasterRegistry feature.

Well if you already made your decision, I don't think I can do much to change it. The least we could do is to fix it to make it actually async (which is #1601). If you still have other concerns, I think we'd end up blocking 2.3.0 (which is very close AFAICT, based on jiras from @ndimiduk). Let's see what other reviewers think? Thanks.

Ping @ndimiduk and @saintstack , what do you guys think? I've replied on #1601 , at least the current implementation does not make sense to me, there is no reason that why we can only support NettyRpcClient.
FWIW, I do not see any advantages on moving the logic from AsyncRpcRetryingCaller down to the rpc framework, except that the MasterRegistry can make use of it, but implementing the logic in MasterRegistry only requires a very small amount of code piece, and can do better error handling than implementing in the rpc framework, so I do not think it worths.
Thanks.

Ping @ndimiduk and @saintstack , what do you guys think? I've replied on #1601 , at least the current implementation does not make sense to me, there is no reason that why we can only support NettyRpcClient.

Your comments on #1601 make sense to me. Thanks for taking a look. It was a misunderstanding on my part that the BlockingRpcConnection implementation always defaulted to a blocking channel implementation, I took a closer look at the code after your comments and that cleared it up. This means it is much easier to support all RpcClients if we wrap the channels in HedgedRpcChannel. So, I think this can be fixed.
I think the whole discussion now boils down to whether we want to have the abstraction of hedging in RPC layer or not.

Looks like your opinion is no.
My take, I definitely understand your argument and see where you are coming from but I think the abstraction doesn't hurt (as long as it is implemented correctly). So I have a slight preference to include it in the RPC layer and I don't mind if the majority vote is the other way.
Do other reviewers/followers have any strong opinion either way?

After reading the above:
It was a mistake suggesting you generalize hedged reads Bharath -- at least for branch-2. I apologize if it made you do more work.
On read-replicas in RPC tier, it strikes me that this an base-special in need of support from tiers above RPC? It won't fit?
On the notion that the hedged reads addition to RPC implies our building a generic, feature-ful, RPC lib, let us take pause here (sorry if my suggestion that hedged reads be made generally available in RPC helped imply this). Lets not do this. Lets see if we can use an existing RPC lib instead (it may not be possible given the reminder above that retries, read-replicas, and hedging factor info from higher tiers). The Duo async refactor helped undo our RPC tangle.  If we could plug in a GRPC, perf allowing, it would be fun being able to just enable ‘pushback’, controlled delay, tracing, etc., because we are up on an RPC lib that just supports these abilities and others (May not be possible in the hbase context but worth investigation).
Duo's reminder that we have to be careful when it comes to almost-there optional code is timely because too often, even with the best of intentions, the stuff is not enabled and rots.
I'm game to help out here how ever I can.

Seems we've lead @bharathv down a rabbit hole. These changes are part of a feature new for 2.3.0, so I prefer that they are settled before the release. I'm still in the process of setting up my infrastructure for running ITBLL tests in the peculiarities of my environment (see my recent patches around the chaos monkey tools). Thus there's still time. Please take the time to see this resolved before the first RC, whichever direction you choose to take it. Go ahead and mark appropriate JIRAs as blockers for 2.3.0.
My one request is that we update the class names, class-level javadoc, and package level javadoc to more clearly describe what's going on here and why. It seems that what structures we have in place are not enough for multiple developers familiar with the codebase to understand the subtleties of this subsystem. No offense @Apache9, but more people than just you need to be able to provide meaningful code review on our RPC implementation.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 47s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 34s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 52s
master passed

+1 :green_heart:
checkstyle
2m 22s
master passed

+1 :green_heart:
spotbugs
4m 44s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 41s
the patch passed

-0 :warning:
checkstyle
0m 37s
hbase-client: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-0 :warning:
whitespace
0m  0s
The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
hadoopcheck
14m 55s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
5m 31s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 38s
The patch does not generate ASF License warnings.

52m 27s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 6f74baa32cc6 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0632e9893f

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-general-check/output/diff-checkstyle-hbase-client.txt

whitespace
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-general-check/output/whitespace-eol.txt

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 32s
Docker mode activated.

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 28s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 23s
master passed

+1 :green_heart:
compile
1m 40s
master passed

+1 :green_heart:
shadedjars
4m 58s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 18s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 23s
the patch passed

+1 :green_heart:
compile
1m 42s
the patch passed

+1 :green_heart:
javac
1m 42s
the patch passed

+1 :green_heart:
shadedjars
4m 58s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 20s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 12s
hbase-common in the patch passed.

-1 :x:
unit
0m 44s
hbase-client in the patch failed.

+1 :green_heart:
unit
133m 40s
hbase-server in the patch passed.

162m 15s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 78e6f2b62b30 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0632e9893f

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-client.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/testReport/

Max. process+thread count
4636 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 48s
the patch passed

+1 :green_heart:
compile
2m 19s
the patch passed

+1 :green_heart:
javac
2m 19s
the patch passed

+1 :green_heart:
shadedjars
6m 15s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 29s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 44s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 56s
hbase-common in the patch passed.

-1 :x:
unit
1m  7s
hbase-client in the patch failed.

+1 :green_heart:
unit
207m 58s
hbase-server in the patch passed.

245m  2s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 7aa9e4c30a2c 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 0632e9893f

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-client.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/testReport/

Max. process+thread count
2992 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 46s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 25s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 21s
master passed

+1 :green_heart:
checkstyle
2m 28s
master passed

+1 :green_heart:
spotbugs
5m 21s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 17s
the patch passed

+1 :green_heart:
checkstyle
2m 36s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
13m 14s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
6m 17s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 38s
The patch does not generate ASF License warnings.

51m 59s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 76fc8d22749f 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fdbf45886d

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 42s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 34s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 39s
master passed

+1 :green_heart:
compile
2m  8s
master passed

+1 :green_heart:
shadedjars
6m 21s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 23s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 26s
the patch passed

+1 :green_heart:
compile
2m  3s
the patch passed

+1 :green_heart:
javac
2m  3s
the patch passed

+1 :green_heart:
shadedjars
6m 30s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 34s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 37s
hbase-common in the patch passed.

-1 :x:
unit
0m 51s
hbase-client in the patch failed.

+1 :green_heart:
unit
139m 40s
hbase-server in the patch passed.

175m  2s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux cabba8730e9e 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fdbf45886d

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-client.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/testReport/

Max. process+thread count
3937 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 24s
the patch passed

+1 :green_heart:
compile
2m 10s
the patch passed

+1 :green_heart:
javac
2m 10s
the patch passed

+1 :green_heart:
shadedjars
5m 48s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 16s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 25s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 43s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 49s
hbase-common in the patch passed.

-1 :x:
unit
0m 58s
hbase-client in the patch failed.

+1 :green_heart:
unit
189m  1s
hbase-server in the patch passed.

223m 58s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 38d5ad210d75 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fdbf45886d

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-client.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/testReport/

Max. process+thread count
3420 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Looks like the test class is missing a class rule (precommit failure).

Ya, my question was about the word "retries". That will show up in the exception message (IIUC). These give a false impression that things are being retried, right (when in reality they are hedged, in some sense).

I think query multiple masters could also be some types of retry? If this master is not available, we just try another, and if all are failed we will return the exception to you.

I was thinking about Call#setException(), which cleans up the caller state and propagates the exception to the the future callback? For example, if a master is hung and the RPC is hung, that state would be cleaned up quicker.

Not a big deal? Only a small amount of memory. Implementing this will lead to a more complicated logic, we have to reference the CompletableFutures for other requests and call cancel on them, and we also need to deal with the cancel event and do the clean up work. Comparing to the benefits, I do not think it worths...

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 37s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 34s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 37s
master passed

+1 :green_heart:
checkstyle
1m 55s
master passed

+1 :green_heart:
spotbugs
3m 45s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 27s
the patch passed

+1 :green_heart:
checkstyle
1m 50s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 47s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
5m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 37s
The patch does not generate ASF License warnings.

43m  8s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux b456a0c97f8b 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 3d96007c37

Max. process+thread count
95 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 55s
the patch passed

+1 :green_heart:
compile
1m 55s
the patch passed

+1 :green_heart:
javac
1m 55s
the patch passed

+1 :green_heart:
shadedjars
5m  6s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 17s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 24s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 33s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m  2s
hbase-client in the patch passed.

+1 :green_heart:
unit
123m 54s
hbase-server in the patch passed.

155m  7s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3705b7c31489 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 3d96007c37

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/testReport/

Max. process+thread count
4196 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 37s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 33s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 36s
master passed

+1 :green_heart:
compile
1m 47s
master passed

+1 :green_heart:
shadedjars
5m 11s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 21s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 26s
the patch passed

+1 :green_heart:
compile
1m 42s
the patch passed

+1 :green_heart:
javac
1m 42s
the patch passed

+1 :green_heart:
shadedjars
4m 53s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 20s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m  2s
hbase-client in the patch passed.

+1 :green_heart:
unit
134m 43s
hbase-server in the patch passed.

164m 31s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1593

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d6b79fa1ed48 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 3d96007c37

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/testReport/

Max. process+thread count
4390 (vs. ulimit of 12500)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1593/6/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.


Wings Fix!

first i want to add a bug fix with wings:
if(!Main.settings.getConfig().contains("Settings.Clouds")){

TO:

if(Main.settings.getConfig().contains("Settings.Clouds")){

a small update:
so the Clouds are working on fly:
@EventHandler
    public void onFly(PlayerToggleFlightEvent e){
        Player player = e.getPlayer();
        if(Api.inTerritory(player)||Api.inWingsRegion(player.getLocation())){
            ItemStack boots = player.getEquipment().getBoots();
            if(Main.CE.hasEnchantments(boots)){
                if(Main.CE.hasEnchantment(boots, CEnchantments.WINGS)){
                    if(CEnchantments.WINGS.isEnabled()){
                        if(e.isFlying()){
                            onStart();
                            e.setCancelled(true);
                            player.setFlying(true);
                            Flying.add(player);
                        }else{
                            Flying.remove(player);
                        }
                    }
                }
            }
        }
    }

Thank you  I have fixed the wings. The onStart(); only goes in the main on the onEnable because it runs controls all the players wings.


Bail out in the middle of traverse

Would be nice to be able to break in the middle of forEach() or map().
Useful in cases you're traversing in order to find something and don't need to continued after you found it.

this.stop()
E.g.
var treedata = [{
  a: {
    block: true,
    ab: {
      name: "ab leaf"
    }
  },
  b: {
    stop: true,
    bc: {
      name: "bc leaf",
    }
  },
  c: {
    cd: {
      name: "cd leaf"
    }
  }
}]

result = traverse(treedata).map(function (item) {
  item.visited = true;
  if (item.block) {
    this.block();
  } else if (item.stop) {
    this.stop();
  }
});

console.log(JSON.stringify(result, null, 2));

Output:
[
  {
    "a": {
      "block": true,
      "ab": {
        "name": "ab leaf"
      },
      "visited": true
    },
    "b": {
      "stop": true,
      "bc": {
        "name": "bc leaf"
      },
      "visited": true
    },
    "c": {
      "cd": {
        "name": "cd leaf"
      }
    },
    "visited": true
  }
]

Where are stop() and block() documented?

forEach + stop can do the job here but wouldn't it be sensible to have a find method? (which is a very frequent use case for any kind of traversal). We could just pass a value and optionally the name of the field in case the structure has nested objects.


Remove nmap from Jenkins slaves

I added nmap to the Jenkins slaves so that we could port-scan our
external-facing IP addresses. The prototype for that was in:
https://github.gds/gds/govuk-provisioning/commit/241711aba3bf99d1295c864ff6812da1341bb5fe
https://github.gds/gds/govuk-provisioning/pull/528
The above prototype wasn't merged, so clean up and remove nmap from the
Jenkins slaves.

Merge away.