Connection reset when using websocket with proxy_protocol

Environment
Docker image erlio/docker-vernemq:1.5.0

VerneMQ Version: 1.5.0
OS: Debian Jessie
Erlang/OTP version (if building from source):

vernemq.conf.local:
log.console=console
log.console.level=debug
allow_anonymous=on
listener.ws.proxy_protocol = on
listener.ws.default = <IP_ADDRESS>:8080

Expected behavior

Established connection

Actual behaviour
Using python paho-mqtt:
ConnectionResetError: [Errno 104] Connection reset by peer
When removing listener.ws.proxy_protocol = on everything works as expected.
This might be related to https://github.com/erlio/vernemq/issues/524
config is OK
-config /var/lib/vernemq/generated.configs/app.2<IP_ADDRESS>.07.56.config -args_file /etc/vernemq/vm.args -vm_args /etc/vernemq/vm.args
Exec:  /usr/lib/vernemq/erts-<IP_ADDRESS>/bin/erlexec -boot /usr/lib/vernemq/releases/1.5.0/vernemq               -config /var/lib/vernemq/generated.configs/app.2<IP_ADDRESS>.07.56.config -args_file /etc/vernemq/vm.args -vm_args /etc/vernemq/vm.args              -pa /usr/lib/vernemq/lib/erlio-patches -- console -noshell -noinput
Root: /usr/lib/vernemq

=INFO REPORT==== 15-Oct-2018::07:07:58 ===
    alarm_handler: {set,{system_memory_high_watermark,[]}}
07:07:58.471 [debug] Lager installed handler {lager_file_backend,"/var/log/vernemq/error.log"} into lager_event
07:07:58.482 [debug] Lager installed handler error_logger_lager_h into error_logger
07:07:58.514 [debug] Supervisor gr_param_sup started gr_param:start_link(gr_lager_default_tracer_params) at pid <0.187.0>
07:07:58.514 [debug] Supervisor gr_counter_sup started gr_counter:start_link(gr_lager_default_tracer_counters) at pid <0.188.0>
07:07:58.514 [debug] Supervisor gr_manager_sup started gr_manager:start_link(gr_lager_default_tracer_params_mgr, gr_lager_default_tracer_params, []) at pid <0.189.0>
07:07:58.515 [debug] Supervisor gr_manager_sup started gr_manager:start_link(gr_lager_default_tracer_counters_mgr, gr_lager_default_tracer_counters, [{input,0},{filter,0},{output,0}]) at pid <0.190.0>
07:07:58.731 [info] Application lager started on node<EMAIL_ADDRESS>07:07:58.750 [debug] Supervisor vmq_plugin_sup started vmq_plugin_mgr:start_link() at pid <0.196.0>
07:07:58.750 [info] Application vmq_plugin started on node<EMAIL_ADDRESS>07:07:58.750 [info] Application ssl_verify_fun started on node<EMAIL_ADDRESS>07:07:58.751 [info] Application epgsql started on node<EMAIL_ADDRESS>07:07:58.770 [info] read state from file {[{[{actor,<<66,228,220,62,84,115,95,14,148,86,207,149,172,39,52,70,212,51,1,160>>}],1}],{dict,1,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[['VerneMQ@<IP_ADDRESS>',{[{actor,<<66,228,220,62,84,115,95,14,148,86,207,149,172,39,52,70,212,51,1,160>>}],1}]],[],[],[],[],[],[],[],[],[],[],[],[]}}},{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}}}
07:07:58.770 [info] writing state {[{[{actor,<<66,228,220,62,84,115,95,14,148,86,207,149,172,39,52,70,212,51,1,160>>}],1}],{dict,1,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[['VerneMQ@<IP_ADDRESS>',{[{actor,<<66,228,220,62,84,115,95,14,148,86,207,149,172,39,52,70,212,51,1,160>>}],1}]],[],[],[],[],[],[],[],[],[],[],[],[]}}},{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}}} to disk <<75,2,131,80,0,0,0,248,120,1,203,96,206,97,96,96,96,204,96,130,82,41,12,172,137,201,37,249,69,185,64,81,17,167,39,119,236,66,138,227,249,166,132,157,159,186,70,221,196,237,138,49,227,130,172,68,198,172,12,206,20,6,150,148,204,228,146,68,198,68,1,32,228,72,12,72,52,200,16,200,66,3,25,140,96,49,176,201,32,130,41,133,65,40,44,181,40,47,213,55,208,193,208,220,72,207,208,92,207,64,207,152,52,171,81,172,64,184,131,129,8,119,160,104,5,0,72,187,75,98>>
07:07:58.778 [debug] Supervisor plumtree_sup started plumtree_metadata_leveldb_iterator_sup:start_link() at pid <0.205.0>
07:07:58.807 [info] Datadir /var/lib/vernemq/meta/meta/0 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,60283058}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.813 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(0, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.207.0>
07:07:58.813 [info] Datadir /var/lib/vernemq/meta/meta/1 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,42120244}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.824 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(1, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.209.0>
07:07:58.824 [info] Datadir /var/lib/vernemq/meta/meta/2 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,42990778}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.832 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(2, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.210.0>
07:07:58.832 [info] Datadir /var/lib/vernemq/meta/meta/3 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,32818057}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.838 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(3, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.211.0>
07:07:58.839 [info] Datadir /var/lib/vernemq/meta/meta/4 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,43267449}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.846 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(4, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.212.0>
07:07:58.846 [info] Datadir /var/lib/vernemq/meta/meta/5 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,56241811}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.852 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(5, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.213.0>
07:07:58.853 [info] Datadir /var/lib/vernemq/meta/meta/6 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,34902334}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.859 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(6, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.214.0>
07:07:58.860 [info] Datadir /var/lib/vernemq/meta/meta/7 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,55610643}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.867 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(7, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.215.0>
07:07:58.867 [info] Datadir /var/lib/vernemq/meta/meta/8 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,51852124}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.875 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(8, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.216.0>
07:07:58.875 [info] Datadir /var/lib/vernemq/meta/meta/9 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,59797396}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.881 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(9, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.217.0>
07:07:58.881 [info] Datadir /var/lib/vernemq/meta/meta/10 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,38722050}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.890 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(10, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.218.0>
07:07:58.891 [info] Datadir /var/lib/vernemq/meta/meta/11 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,6},{use_bloomfilter,true},{write_buffer_size,62039370}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:58.897 [debug] Supervisor plumtree_metadata_leveldb_instance_sup started plumtree_metadata_leveldb_instance:start_link(11, [{sync,false},{total_leveldb_mem_percent,6},{use_bloomfilter,true}]) at pid <0.219.0>
07:07:58.897 [debug] Supervisor plumtree_sup started plumtree_metadata_leveldb_instance_sup:start_link() at pid <0.206.0>
07:07:58.906 [debug] Supervisor plumtree_sup started plumtree_peer_service_gossip:start_link() at pid <0.220.0>
07:07:58.914 [debug] Supervisor plumtree_sup started plumtree_peer_service_events:start_link() at pid <0.221.0>
07:07:58.928 [debug] 0ms mailbox traversal, schedule next lazy broadcast in 10000ms, the min interval is 10000ms
07:07:58.928 [debug] Supervisor plumtree_sup started plumtree_broadcast:start_link() at pid <0.222.0>
07:07:58.932 [debug] Supervisor plumtree_sup started plumtree_metadata_manager:start_link() at pid <0.223.0>
07:07:58.958 [debug] Lager installed handler lager_backend_throttle into lager_event
07:07:58.976 [debug] Supervisor plumtree_sup started plumtree_metadata_hashtree:start_link() at pid <0.224.0>
07:07:58.977 [info] Application plumtree started on node<EMAIL_ADDRESS>07:07:59.030 [debug] Supervisor hackney_sup started hackney_manager:start_link() at pid <0.231.0>
07:07:59.035 [info] Application hackney started on node<EMAIL_ADDRESS>07:07:59.050 [debug] Supervisor inets_sup started ftp_sup:start_link() at pid <0.236.0>
07:07:59.108 [debug] Supervisor httpc_profile_sup started httpc_manager:start_link(default, only_session_cookies, inets) at pid <0.239.0>
07:07:59.108 [debug] Supervisor httpc_sup started httpc_profile_sup:start_link([{httpc,{default,only_session_cookies}}]) at pid <0.238.0>
07:07:59.120 [debug] Supervisor httpc_sup started httpc_handler_sup:start_link() at pid <0.240.0>
07:07:59.120 [debug] Supervisor inets_sup started httpc_sup:start_link([{httpc,{default,only_session_cookies}}]) at pid <0.237.0>
07:07:59.133 [debug] Supervisor inets_sup started httpd_sup:start_link([]) at pid <0.241.0>
07:07:59.136 [debug] Supervisor inets_sup started tftp_sup:start_link([]) at pid <0.242.0>
07:07:59.137 [info] Application inets started on node<EMAIL_ADDRESS>07:07:59.137 [info] Application xmerl started on node<EMAIL_ADDRESS>07:07:59.221 [debug] loading modules: [vmq_plumtree,vmq_plumtree_app,vmq_plumtree_sup]
07:07:59.221 [info] Application vmq_plumtree started on node<EMAIL_ADDRESS>07:07:59.249 [info] Try to start vmq_plumtree: ok
07:07:59.312 [debug] Supervisor vmq_server_sup started vmq_config:start_link() at pid <0.253.0>
07:07:59.323 [debug] datadir /var/lib/vernemq/msgstore/1 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,56690880}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.329 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(1) at pid <0.256.0>
07:07:59.330 [debug] datadir /var/lib/vernemq/msgstore/2 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,50002691}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.335 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(2) at pid <0.257.0>
07:07:59.336 [debug] datadir /var/lib/vernemq/msgstore/3 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,55594612}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.345 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(3) at pid <0.258.0>
07:07:59.346 [debug] datadir /var/lib/vernemq/msgstore/4 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,34461636}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.353 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(4) at pid <0.259.0>
07:07:59.354 [debug] datadir /var/lib/vernemq/msgstore/5 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,35880821}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.358 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(5) at pid <0.260.0>
07:07:59.359 [debug] datadir /var/lib/vernemq/msgstore/6 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,35424213}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.366 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(6) at pid <0.261.0>
07:07:59.367 [debug] datadir /var/lib/vernemq/msgstore/7 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,50467760}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.372 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(7) at pid <0.262.0>
07:07:59.372 [debug] datadir /var/lib/vernemq/msgstore/8 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,54928324}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.377 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(8) at pid <0.263.0>
07:07:59.378 [debug] datadir /var/lib/vernemq/msgstore/9 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,48728551}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.383 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(9) at pid <0.264.0>
07:07:59.384 [debug] datadir /var/lib/vernemq/msgstore/10 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,45138616}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.390 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(10) at pid <0.265.0>
07:07:59.391 [debug] datadir /var/lib/vernemq/msgstore/11 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,31492447}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.402 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(11) at pid <0.266.0>
07:07:59.403 [debug] datadir /var/lib/vernemq/msgstore/12 options for LevelDB: [{open,[{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,true},{create_if_missing,true},{delete_threshold,1000},{eleveldb_threads,71},{fadvise_willneed,false},{limited_developer_mem,false},{sst_block_size,4096},{tiered_slow_level,0},{total_leveldb_mem_percent,70},{use_bloomfilter,true},{write_buffer_size,31614009}]},{read,[{verify_checksums,true}]},{write,[{sync,false}]},{fold,[{verify_checksums,true},{fill_cache,false}]}]
07:07:59.410 [debug] Supervisor vmq_lvldb_store_sup started vmq_lvldb_store:start_link(12) at pid <0.267.0>
07:07:59.642 [debug] Supervisor vmq_server_sup started vmq_lvldb_store_sup:start_link() at pid <0.255.0>
07:07:59.650 [debug] Supervisor vmq_server_sup started vmq_crl_srv:start_link() at pid <0.272.0>
07:07:59.657 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_1, vmq_queue_sup_1_tab, 5, 10) at pid <0.274.0>
07:07:59.657 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_2, vmq_queue_sup_2_tab, 5, 10) at pid <0.275.0>
07:07:59.658 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_3, vmq_queue_sup_3_tab, 5, 10) at pid <0.276.0>
07:07:59.658 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_4, vmq_queue_sup_4_tab, 5, 10) at pid <0.277.0>
07:07:59.658 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_5, vmq_queue_sup_5_tab, 5, 10) at pid <0.278.0>
07:07:59.659 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_6, vmq_queue_sup_6_tab, 5, 10) at pid <0.279.0>
07:07:59.659 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_7, vmq_queue_sup_7_tab, 5, 10) at pid <0.280.0>
07:07:59.659 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_8, vmq_queue_sup_8_tab, 5, 10) at pid <0.281.0>
07:07:59.660 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_9, vmq_queue_sup_9_tab, 5, 10) at pid <0.282.0>
07:07:59.660 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_10, vmq_queue_sup_10_tab, 5, 10) at pid <0.283.0>
07:07:59.660 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_11, vmq_queue_sup_11_tab, 5, 10) at pid <0.284.0>
07:07:59.661 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_12, vmq_queue_sup_12_tab, 5, 10) at pid <0.285.0>
07:07:59.661 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_13, vmq_queue_sup_13_tab, 5, 10) at pid <0.286.0>
07:07:59.661 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_14, vmq_queue_sup_14_tab, 5, 10) at pid <0.287.0>
07:07:59.662 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_15, vmq_queue_sup_15_tab, 5, 10) at pid <0.288.0>
07:07:59.662 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_16, vmq_queue_sup_16_tab, 5, 10) at pid <0.289.0>
07:07:59.662 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_17, vmq_queue_sup_17_tab, 5, 10) at pid <0.290.0>
07:07:59.663 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_18, vmq_queue_sup_18_tab, 5, 10) at pid <0.291.0>
07:07:59.663 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_19, vmq_queue_sup_19_tab, 5, 10) at pid <0.292.0>
07:07:59.663 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_20, vmq_queue_sup_20_tab, 5, 10) at pid <0.293.0>
07:07:59.663 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_21, vmq_queue_sup_21_tab, 5, 10) at pid <0.294.0>
07:07:59.664 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_22, vmq_queue_sup_22_tab, 5, 10) at pid <0.295.0>
07:07:59.664 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_23, vmq_queue_sup_23_tab, 5, 10) at pid <0.296.0>
07:07:59.664 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_24, vmq_queue_sup_24_tab, 5, 10) at pid <0.297.0>
07:07:59.665 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_25, vmq_queue_sup_25_tab, 5, 10) at pid <0.298.0>
07:07:59.665 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_26, vmq_queue_sup_26_tab, 5, 10) at pid <0.299.0>
07:07:59.665 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_27, vmq_queue_sup_27_tab, 5, 10) at pid <0.300.0>
07:07:59.666 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_28, vmq_queue_sup_28_tab, 5, 10) at pid <0.301.0>
07:07:59.666 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_29, vmq_queue_sup_29_tab, 5, 10) at pid <0.302.0>
07:07:59.666 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_30, vmq_queue_sup_30_tab, 5, 10) at pid <0.303.0>
07:07:59.667 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_31, vmq_queue_sup_31_tab, 5, 10) at pid <0.304.0>
07:07:59.667 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_32, vmq_queue_sup_32_tab, 5, 10) at pid <0.305.0>
07:07:59.667 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_33, vmq_queue_sup_33_tab, 5, 10) at pid <0.306.0>
07:07:59.668 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_34, vmq_queue_sup_34_tab, 5, 10) at pid <0.307.0>
07:07:59.668 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_35, vmq_queue_sup_35_tab, 5, 10) at pid <0.308.0>
07:07:59.668 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_36, vmq_queue_sup_36_tab, 5, 10) at pid <0.309.0>
07:07:59.668 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_37, vmq_queue_sup_37_tab, 5, 10) at pid <0.310.0>
07:07:59.669 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_38, vmq_queue_sup_38_tab, 5, 10) at pid <0.311.0>
07:07:59.669 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_39, vmq_queue_sup_39_tab, 5, 10) at pid <0.312.0>
07:07:59.669 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_40, vmq_queue_sup_40_tab, 5, 10) at pid <0.313.0>
07:07:59.670 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_41, vmq_queue_sup_41_tab, 5, 10) at pid <0.314.0>
07:07:59.670 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_42, vmq_queue_sup_42_tab, 5, 10) at pid <0.315.0>
07:07:59.670 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_43, vmq_queue_sup_43_tab, 5, 10) at pid <0.316.0>
07:07:59.671 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_44, vmq_queue_sup_44_tab, 5, 10) at pid <0.317.0>
07:07:59.671 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_45, vmq_queue_sup_45_tab, 5, 10) at pid <0.318.0>
07:07:59.671 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_46, vmq_queue_sup_46_tab, 5, 10) at pid <0.319.0>
07:07:59.672 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_47, vmq_queue_sup_47_tab, 5, 10) at pid <0.320.0>
07:07:59.672 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_48, vmq_queue_sup_48_tab, 5, 10) at pid <0.321.0>
07:07:59.672 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_49, vmq_queue_sup_49_tab, 5, 10) at pid <0.322.0>
07:07:59.673 [debug] Supervisor vmq_queue_sup_sup started vmq_queue_sup:start_link(infinity, vmq_queue_sup_50, vmq_queue_sup_50_tab, 5, 10) at pid <0.323.0>
07:07:59.673 [debug] Supervisor vmq_server_sup started vmq_queue_sup_sup:start_link(infinity, 5, 10) at pid <0.273.0>
07:07:59.692 [debug] Supervisor vmq_reg_sup started vmq_reg_mgr:start_link() at pid <0.325.0>
07:07:59.699 [debug] Supervisor vmq_reg_sup started vmq_retain_srv:start_link() at pid <0.328.0>
07:07:59.706 [debug] Supervisor vmq_reg_sup started vmq_reg_sync_action_sup:start_link() at pid <0.330.0>
07:07:59.709 [debug] Supervisor vmq_reg_sup started vmq_reg_sync:start_link() at pid <0.331.0>
07:07:59.713 [debug] Supervisor vmq_reg_sup started vmq_reg_trie:start_link() at pid <0.332.0>
07:07:59.713 [debug] Supervisor vmq_server_sup started vmq_reg_sup:start_link() at pid <0.324.0>
07:07:59.716 [info] loaded 0 subscriptions into vmq_reg_trie
07:07:59.722 [debug] Supervisor vmq_cluster_node_sup started vmq_cluster_mon:start_link() at pid <0.336.0>
07:07:59.722 [debug] Supervisor vmq_server_sup started vmq_cluster_node_sup:start_link() at pid <0.335.0>
07:07:59.730 [info] cluster event handler 'vmq_cluster' registered
07:07:59.736 [debug] Supervisor vmq_server_sup started vmq_sysmon:start_link() at pid <0.337.0>
07:07:59.751 [debug] Supervisor vmq_metrics_sup started vmq_metrics:start_link() at pid <0.339.0>
07:07:59.755 [debug] Supervisor vmq_metrics_sup started vmq_graphite:start_link() at pid <0.341.0>
07:07:59.759 [debug] Supervisor vmq_metrics_sup started vmq_systree:start_link() at pid <0.342.0>
07:07:59.759 [debug] Supervisor vmq_server_sup started vmq_metrics_sup:start_link() at pid <0.338.0>
07:08:00.381 [debug] Supervisor vmq_acl_sup started vmq_acl_reloader:start_link() at pid <0.347.0>
07:08:00.381 [info] Application vmq_acl started on node<EMAIL_ADDRESS>07:08:00.383 [debug] loading modules: [vmq_acl,vmq_acl_app,vmq_acl_cli,vmq_acl_reloader,vmq_acl_sup]
07:08:00.465 [debug] Supervisor vmq_passwd_sup started vmq_passwd_reloader:start_link() at pid <0.354.0>
07:08:00.466 [info] Application vmq_passwd started on node<EMAIL_ADDRESS>07:08:00.467 [debug] loading modules: [vmq_passwd,vmq_passwd_app,vmq_passwd_cli,vmq_passwd_reloader,vmq_passwd_sup]
07:08:00.539 [debug] Supervisor {<0.357.0>,ranch_listener_sup} started ranch_conns_sup:start_link({{0,0,0,0},8080}, worker, 5000, vmq_ranch_proxy_protocol, 5000, cowboy_protocol) at pid <0.358.0>
07:08:00.548 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.360.0>
07:08:00.549 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.361.0>
07:08:00.549 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.362.0>
07:08:00.550 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.363.0>
07:08:00.550 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.364.0>
07:08:00.550 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.365.0>
07:08:00.551 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.366.0>
07:08:00.551 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.367.0>
07:08:00.551 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.368.0>
07:08:00.552 [debug] Supervisor {<0.359.0>,ranch_acceptors_sup} started ranch_acceptor:start_link({proxy_socket,#Port<0.9222>,undefined,[{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}],...}, vmq_ranch_proxy_protocol, <0.358.0>) at pid <0.369.0>
07:08:00.553 [debug] Supervisor {<0.357.0>,ranch_listener_sup} started ranch_acceptors_sup:start_link({{0,0,0,0},8080}, 10, vmq_ranch_proxy_protocol, [{ip,{0,0,0,0}},{port,8080},{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}]) at pid <0.359.0>
07:08:00.553 [debug] Supervisor ranch_sup started ranch_listener_sup:start_link({{0,0,0,0},8080}, 10, vmq_ranch_proxy_protocol, [{ip,{0,0,0,0}},{port,8080},{nodelay,true},{linger,{true,0}},{send_timeout,30000},{send_timeout_close,...}], cowboy_protocol, [{env,[{dispatch,[{'_',[],[{[<<"mqtt">>],[],vmq_websocket,[{mountpoint,[]},{allowed_protocol_versions,...}]}]}]}]}]) at pid <0.357.0>
07:08:00.553 [info] Application vmq_server started on node<EMAIL_ADDRESS>07:08:08.929 [debug] 0ms mailbox traversal, schedule next lazy broadcast in 10000ms, the min interval is 10000ms

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
07:19:06.691308 IP (tos 0x0, ttl 64, id 31375, offset 0, flags [DF], proto TCP (6), length 60)
    testcontainer.40261 > 1eb8b33596a5.http-alt: Flags [S], cksum 0x585c (incorrect -> 0x4bfc), seq<PHONE_NUMBER>, win 29200, options [mss 1460,sackOK,TS val 9209719 ecr 0,nop,wscale 7], length 0
07:19:06.691337 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    1eb8b33596a5.http-alt > testcontainer.40261: Flags [S.], cksum 0x585c (incorrect -> 0x06c8), seq<PHONE_NUMBER>, ack<PHONE_NUMBER>, win 28960, options [mss 1460,sackOK,TS val 9209719 ecr 9209719,nop,wscale 7], length 0
07:19:06.691361 IP (tos 0x0, ttl 64, id 31376, offset 0, flags [DF], proto TCP (6), length 52)
    testcontainer.40261 > 1eb8b33596a5.http-alt: Flags [.], cksum 0x5854 (incorrect -> 0xa5cf), ack 1, win 229, options [nop,nop,TS val 9209719 ecr 9209719], length 0
07:19:06.691887 IP (tos 0x0, ttl 64, id 31377, offset 0, flags [DF], proto TCP (6), length 261)
    testcontainer.40261 > 1eb8b33596a5.http-alt: Flags [P.], cksum 0x5925 (incorrect -> 0xf65f), seq 1:210, ack 1, win 229, options [nop,nop,TS val 9209719 ecr 9209719], length 209: HTTP, length: 209
	GET /mqtt HTTP/1.1
	Host: mqtt:8080
	Upgrade: websocket
	Connection: Upgrade
	Origin: https://mqtt:8080
	Sec-WebSocket-Key: dF8hovdYRxy0fe2oBpU7NA==
	Sec-Websocket-Version: 13
	Sec-Websocket-Protocol: mqtt

07:19:06.691902 IP (tos 0x0, ttl 64, id 17805, offset 0, flags [DF], proto TCP (6), length 52)
    1eb8b33596a5.http-alt > testcontainer.40261: Flags [.], cksum 0x5854 (incorrect -> 0xa4f8), ack 210, win 235, options [nop,nop,TS val 9209719 ecr 9209719], length 0
07:19:06.692006 IP (tos 0x0, ttl 64, id 17806, offset 0, flags [DF], proto TCP (6), length 52)
    1eb8b33596a5.http-alt > testcontainer.40261: Flags [R.], cksum 0x5854 (incorrect -> 0xa4f4), seq 1, ack 210, win 235, options [nop,nop,TS val 9209719 ecr 9209719], length 0

@cbenhagen thanks for opening the issue!
Quick question: what TCP proxy/balancer are you using? are you configureing the proxy protocol too there?

Thank you for the quick response! I use NGINX and it is already configured. But to simplify the problem I tried to make a connection from another container. Without even using the proxy.

Ok. Do things work with NGINX?
In any case, without an actual proxy the proxy protocol will not work.

Oh interesting. So I would need a second listener for internal traffic?
No it does not work with NGINX but I did not try to fix it before as I was expecting it to work with and without a proxy and wanted to keep it simple. Are there any specific requirements for the proxy? Any example NGINX configs you could point me to?

Yes, you would need to use 2 different listeners if you want to have both options (normal & proxied).
Proxy should forward Source IP, Source Port, this shouldn't need special configuration (for proxy protocol v1). Depending on your use case you would need a little more config than just switching the protocol on (example is TLS etc). I'd refer to NGINX (or respective proxy) documentation to get you started.

Ok I will close this issue as this is definitively not a bug. Sorry for the noise.

No worries, you're welcome asking anytime. Thanks for using VerneMQ :)


OlFeatureInfoHandler tests are flaky

Not solved yet

Hm, does not occur in recent time. Closing it.


bug: $ionicHistory.currentView() is wrong

Type: bug
Platform: all
See the console log output here: http://codepen.io/anon/pen/PwejPO
In Beta 14 $ionicHistory.stateName should be identical to $ionicHistory.currentView().stateName, but the latter consistently lags behind by one step.

You should be using the lifecycle events as of beta14: http://ionicframework.com/docs/api/directive/ionView/

@Ionitron This doesn't seem to fit here...


Code assumes all endpoints are specified using well-formed URIs

The code assumes that all routing endpoints are specified as well-formed URIs.  This is a run-time validation test performed on directives.  However, there is no such constraint in the real world.  For example, a BizTalk Server Send Port may drop files into a folder using non-URI file path.  This validation rules should be removed.

This is a logic bug.  The issue has been resolved be deleting the validation rule from the code.


Playing a .m3u file results in duplicates

With loadfiles_on_start=yes, opening a .m3u file which contains all the files in the directory results in said files added twice to the playlist.
Example:
tree .
.
├── 001.mkv
├── 002.mkv
└── 1.m3u

When opening 1.m3u:

Am I missing something? or maybe adding an option to exclude some file types for the loadfiles_on_start option?
Thanks.

Thanks. That is a recent issue from https://github.com/jonniek/mpv-playlistmanager/issues/88
We fixed it for opening directories, but actually playlists behave the same way as directories. I added a special case handling for m3u to work the same as a directory.


Rfx tile assert

fixes issues reported by @pnowack

bug in winpr_aligned_offset_recalloc
fixes a bug with lifecycle of buffers in rfx_split_message
unifies RFX_MESSAGE tile allocation/deallocation
fixes a few warnings

@freerdp-bot test again please

@freerdp-bot test again please


Changing dependencies so the repo is pip installable

Currently when running "pip install ." we get the following error:
Processing /workdisk/brandon/examples_fork
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [2 lines of output]
      _project_root: /workdisk/brandon/examples_fork
      error in mosaicml-examples setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

This is because of a mis-specified dependency on mosaicml-streaming. See here for a related issue:
https://github.com/mosaicml/composer/pull/1919/files

I think this might want to wait on #90 which is doing a big refactor for pip installability

Fixed now in #90, closing this branch. Thank you @bcui19 !


Non-square avatars displayed at original proportion in share with users modal

In the modal to share the map with organization users (inside the builder), non-square avatars are not correctly sized.

cc @xavijam @nobuti

@josecruz do we want them rounded or as they appear?

We need it rounded, having the same appearance as the big ones


gen_snapshot crash when both --loading_unit_manifest and --print-instructions-sizes-to are passed

Stack trace:
#0  0x00007ffff7d41602 in raise () from libc.so.6
#1  0x00007ffff7d43320 in abort () from libc.so.6
#2  0x0000555556c6d71c in dart::Assert::Fail (this=<optimized out>, format=<optimized out>) at runtime/platform/assert.cc:44
#3  0x0000555556d08ff6 in dart::JSONWriter::AddDartString (this=<optimized out>, this@entry=0x7fffffffcd50, s=..., offset=offset@entry=0, count=<optimized out>, count@entry=-1)
    at runtime/vm/json_writer.cc:399
#4  0x0000555556d095bf in dart::JSONWriter::PrintValueStr (this=0x7fffffffcd50, s=..., offset=<optimized out>, count=<optimized out>) at runtime/vm/json_writer.cc:176
#5  dart::JSONWriter::PrintPropertyStr (this=0x7fffffffcd50, name=<optimized out>, s=..., offset=0, count=-1) at runtime/vm/json_writer.cc:252
#6  0x0000555556cf02ca in dart::ImageWriter::DumpInstructionsSizes (this=0x7fffffffd028) at runtime/vm/object.h:1090
#7  0x0000555556ca1324 in dart::FullSnapshotWriter::WriteProgramSnapshot (this=this@entry=0x7fffffffd1c0, num_base_objects=1011, units=<optimized out>, units@entry=0x7fffffffd350)
    at runtime/vm/clustered_snapshot.cc:6888
#8  0x0000555556ca1645 in dart::FullSnapshotWriter::WriteFullSnapshot (this=0x7fffffffd1c0, data=0x7fffffffd350) at runtime/vm/clustered_snapshot.cc:6950
#9  0x0000555556ad4813 in dart::CreateAppAOTSnapshot (callback=<optimized out>, callback@entry=0x5555568c7550 <dart::bin::StreamingWriteCallback(void*, unsigned char const*, long)>,
    callback_data=0xf85bfc84080, strip=true, as_elf=<optimized out>, debug_callback_data=<optimized out>, units=0x22e951, units@entry=0x7fffffffd350, unit=0x7ffff786e940, program_hash=842629723)
    at runtime/vm/dart_api_impl.cc:6695
#10 0x0000555556ad4f12 in dart::Split (next_callback=next_callback@entry=0x5555568c7660 <dart::bin::NextElfCallback(void*, long, void**, void**)>,
    next_callback_data=next_callback_data@entry=0xf85bfc84380, strip=<optimized out>, as_elf=<optimized out>,
    write_callback=0x5555568c7550 <dart::bin::StreamingWriteCallback(void*, unsigned char const*, long)>, close_callback=<optimized out>) at runtime/vm/dart_api_impl.cc:6764
#11 0x0000555556ad552b in Dart_CreateAppAOTSnapshotAsElfs (next_callback=0x5555568c7660 <dart::bin::NextElfCallback(void*, long, void**, void**)>, next_callback_data=0xf85bfc84380, strip=true,
    write_callback=0x5555568c7550 <dart::bin::StreamingWriteCallback(void*, unsigned char const*, long)>, close_callback=0x5555568c7630 <dart::bin::StreamingCloseCallback(void*)>)
    at runtime/vm/dart_api_impl.cc:6902
#12 0x00005555568c6d77 in dart::bin::CreateAndWritePrecompiledSnapshot () at runtime/bin/gen_snapshot.cc:745
#13 dart::bin::CreateIsolateAndSnapshot (inputs=...) at runtime/bin/gen_snapshot.cc:871
#14 dart::bin::main (argc=<optimized out>, argv=<optimized out>) at runtime/bin/gen_snapshot.cc:983
#15 0x00007ffff7d2dbbd in __libc_start_main () from libc.so.6
#16 0x00005555568c5029 in _start () at ../sysdeps/x86_64/start.S:108

Repro: cl/323858212

cc @rmacnak-google


UNSECURED_PUBLIC_ENDPOINT violations: Hard to track offending application on K8s

Expected behavior
When I see a UNSECURED_PUBLIC_ENDPOINT violation I want to see the offending applications.
In terms of a Kubernetes deployment I only see the ELB with an autogenerated ID, but I would like to see the offending application id.
Step needed
From there you need to know how to resolve the application, e.g. with zkubectl get svc -o wide or by looking up the security group in the AWS console.
It would be nice if this could be done in fullstop already.
Dependencies
K8s apis?

@alexkops you can see all the calls zkubectl (kubectl) does, if you pass --v=9.
API to query to get the information from the default namespace: https:///api/v1/namespaces/default/services

Thanks for raising the issue. Currently Fullstop has no dedicated K8S support, but just applies its normal rule set to the AWS accounts where the clusters are hosted. We need to improve here.

PR #520 ignores the Kubernetes ELBs  for now. We need to rework a good part of that check anyway, since it does not cover ELBv2 at the moment :-/


Security vulnerability reported by dependabot

Dependabot warns:
<EMAIL_ADDRESS>requires<EMAIL_ADDRESS>via a transitive dependency on<EMAIL_ADDRESS>The earliest fixed version is 2.0.1.
nth-check is vulnerable to Inefficient Regular Expression Complexity

That dependancy isn't coming from this repo https://github.com/timarney/react-app-rewired/blob/master/package.json#L18


[Task] Disable add button if vector is already added

If the vector has already been added to the list then disable the button so that it is clear that it cannot be added again.

Jonas had some advice for this one:

have “added” state on an impact vector in the selection tab, when already in ballot, could be a check symbol ✅


Old plugin in registry

It's confusing that there's this new plugin and also this. Can plugins be deleted from the registry, and are you planning to register the new one?

Since there is no further action to be done here I am going to close this issue.


add make target to build geranos

we can switch CI to this instead of go run + sourcing the go setup ...

/approve
/lgtm


Update scalaz-core to 7.3.8

About this PR
📦 Updates org.scalaz:scalaz-core from 7.2.35 to 7.3.8
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

💡 Applied Scalafix Migrations

org.scalaz:scalaz-.*:7.3.0 (created no change)

https://raw.githubusercontent.com/scalaz/scalazfix/v0.1.2/rules/src/main/scala/scalaz/ScalazFix.scala

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalaz", artifactId = "scalaz-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalaz", artifactId = "scalaz-core" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, scalafix-migrations, commit-count:1

Scalaz-concurrent is not aligned.


commentary and code are written in incorrect format on the current buffer

First of all: congrats on the initiative of making an LLM plugin for neovim that incorporates the groq-api with llama. There are countless possibilities for this! And it can be the best copilot alternative (maybe even better for some cases) for those who do not have money for it. Then, the issue: If we're going with the option of interacting with the bot directly from the text file instead of opening a new window somewhere, then it should be written with proper formatting:

We cannot write to a source file of a programming language (like .c, .lua, .javascript, etc.) with plain text like that... it should at least be commented out with //

There's also the issue with ```c which is correct for Discord and some other platforms but makes no sense in a .c file.

I found out that prompting the bot again with "filter out from your answer everything that is not code, including the formatting backticks ```" is effective to make it output pure code in the second iteration. We could filter out the bot response with this second prompt before outputting the final response to the user.

Thank you for the kind words, Vinni! My goal was to make it cheaper to alternate between APIs by only paying for what you use via the API, instead of having subscriptions to ChatGPT, Claude, Gemini, etc. Alternatively, you can use the Groq API, which is currently free (though I suspect this might change).
In my usage, I have been manually deleting the markdown-style backticks. After testing your suggestion of appending "Filter out from your answer everything that is not code, including the formatting backticks ```" to the system prompt in the README.md, I found that it produces a more suitable generation. Thank you! I have updated the README.md accordingly.
As mentioned in the README.md, I want to add support to easily toggle between system prompts and add support for other APIs. I can see many use cases for this.
Once again, thank you for your feedback and help. If you notice any other bugs or have any feature suggestions, please let me know!


Caused by: java.lang.ClassNotFoundException: io.netty.util.concurrent.OrderedEventExecutor

Having this Caused by: java.lang.ClassNotFoundException: io.netty.util.concurrent.OrderedEventExecutor
error in when using Netty 4.1. Please suggest a work around, Thanks

Missing dependencies.

This means you don't have "netty-common" on the class path.


Build all components

[x] Avatar
[x] Badge
[x] Button
[x] Basic Card
[ ] Card Footer
[ ] Pricing Card
[ ] Chart Card
[ ] Store Card
[ ] Gallery Card
[ ] Blog Card
[x] Container
[x] Dropdown
[x] Form
[x] Grid
[x] Header
[x] Icon
[ ] Nav
[x] Page
[x] Page/Website header
[ ] Page/Website navbar
[ ] Page/Website footer
[x] Table
[x] Text
[ ] Map
[x] Alert
[x] Progress
[ ] Stamp

Any Help needed?

Okay, any thing I'll tell when I start

I'll be working on the card footer,

@iamzjohn thanks for your help on these, just to let you know I am currently working on merging this repository into the new and official Tabler react repository you can find it here https://github.com/tabler/tabler-react.
It's nearly up to date with the work we were doing here, as soon as it is, would be good to have you come and join us over there to get involved :)

Thanks @jonthomp, I will subscribe my self and help when possible. But I would like to know if I must stop, cuz I can see that the coding style isin't the same. So do I wait for the merge or I can continue and then can also be merged?

@iamzjohn the main thing that has changed is moving away from PropTypes to flow instead. Everything else should be pretty much the same so I would say continue as you are and then we can merge later

@jonthomp I prefer to wait, and help when the merging end, it looks almost done. And then would be better do not duplicate work merging them.

@iamzjohn ok cool, all the components are now up to date, I haven't merged your footer in case you just want to go ahead and add it in to the new repository yourself?

@jonthomp it's a great opportunity to have  a commit


Allow existing components to be modified using lwc-builder

If there is an existing component we can't edit that directly with builder extension. Need an option to open an existing component and preload the existing configuration, so we can modify that and save it back to the component meta.xml file. I am planning to work on it. Let me know your thoughts.

Yes this would a much appreciated function. As it is now this is only useful for initial creation. But still VERY useful.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Should fix Python building issues (https://github.com/aws/jsii/commit/b4cc08cbeadace4cb1b1539b8387e95763ed0a72).


The format of CLI & API services

All of the returned result of REST API should be JSON format
Keep the original output of CLI

Below is an example....
Use GET http://<IP_ADDRESS>:8080/rules/rule1/status to get the rule status, but the response is not pure json.
Running with metrics: should be removed.
Running with metrics:
{
  "source_demo_0_records_in_total": 0,
  "source_demo_0_records_out_total": 0,
  "source_demo_0_exceptions_total": 0,
  "source_demo_0_process_latency_ms": 0,
  "source_demo_0_buffer_length": 0,
  "source_demo_0_last_invocation": 0,
  "op_preprocessor_demo_0_records_in_total": 0,
  "op_preprocessor_demo_0_records_out_total": 0,
  "op_preprocessor_demo_0_exceptions_total": 0,
  "op_preprocessor_demo_0_process_latency_ms": 0,
  "op_preprocessor_demo_0_buffer_length": 0,
  "op_preprocessor_demo_0_last_invocation": 0,
  "op_project_0_records_in_total": 0,
  "op_project_0_records_out_total": 0,
  "op_project_0_exceptions_total": 0,
  "op_project_0_process_latency_ms": 0,
  "op_project_0_buffer_length": 0,
  "op_project_0_last_invocation": 0,
  "sink_sink_log_0_records_in_total": 0,
  "sink_sink_log_0_records_out_total": 0,
  "sink_sink_log_0_exceptions_total": 0,
  "sink_sink_log_0_process_latency_ms": 0,
  "sink_sink_log_0_buffer_length": 0,
  "sink_sink_log_0_last_invocation": 0,
  "sink_sink_mqtt_0_records_in_total": 0,
  "sink_sink_mqtt_0_records_out_total": 0,
  "sink_sink_mqtt_0_exceptions_total": 0,
  "sink_sink_mqtt_0_process_latency_ms": 0,
  "sink_sink_mqtt_0_buffer_length": 0,
  "sink_sink_mqtt_0_last_invocation": 0
}

Done & close the issue.


Remove Spree.t

Spree.t is no more... It has been removed in favor of I18n.t to prevent
spam on every app that uses solidus_sale_prices.

@DanielePalombo you're on vacation so I'll merge this without approval :trollface:


Document workaround for #3

(this one https://github.com/sphinx-extensions2/sphinx-jinja2/issues/3)

(Sorry, I see now the two branches got mixed up. This one is just about the known issues section)


Feat/go dep

Codecov Report

Merging #16 into master will decrease coverage by 0.39%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master      #16     +/-   ##
=========================================
- Coverage   98.45%   98.06%   -0.4%
=========================================
  Files           3        3
  Lines         907     1033    +126
=========================================
+ Hits          893     1013    +120
- Misses          8       14      +6
  Partials        6        6

Impacted Files
Coverage Δ

hermes.go
73.91% <0%> (-3.87%)
:arrow_down:

default.go
100% <0%> (ø)
:arrow_up:

flat.go
99.58% <0%> (+0.05%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6692b67...f5fd28b. Read the comment docs.


Create index for initial documentation

Create a first version of a docs index page so we have a unified place to link the documentation we'll create in the follow-up PRs.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.29%. Comparing base (017bc30) to head (584f4b3).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #325   +/-   ##
=======================================
  Coverage   93.29%   93.29%
=======================================
  Files          10       10
  Lines         776      776
=======================================
  Hits          724      724
  Misses         52       52

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Status bar on Start page

done via 41d0b6f4655e69494e724a4a0500af1ac2961bc3. But it is again kind of hacky because its not officially supported to do it, so I cannot guarantee it will work as expected.


Implement sending receipt as attachment on successful payment

See previous (base) tasks: #74 ("Invoice email: fixes"), #84 ("Send invoices as email message attachments on membership and event success").
See also: #94 ("Refactor invoice PDF creation").
There is required to pass real generated invoice data to updated email_user methods.

An invoice is something you have to pay, a receipt is for when you have already paid.
Can you do #103? I will do the work needed for sending receipts from paid invoices.

Is that finished now (#84), or we have to complete smth else here?


epic: remove cortex.llamacpp out of cortex-cpp release

Problem
We are supporting multiple engines. It is weird if we only want to use cortex.onnx but still have cortex.llamacpp engine.
Success Criteria
Only release cortex-cpp binary
Sub Issues
Additional context

Done


how to send post request with xml body using afnetworking3x

For general help, please ask on StackOverflow.


Incompatibility with new SeqFilter comand line

Hey guys, I've just downloaded proovread and have installed all the dependencies, but still I'm getting an error message.
command line: ./proovread --sample --pre pr-sample --overwrite --cfg proovread.cfg
Error log:
[Tue Nov  3 17:56:09 2015] Checking short read files
F.antasticus_short.fq
Detected FASTQ format
Estimated short read length: 100 +-0
Estimating approximate number of short reads: 50.0k
[Tue Nov  3 17:56:10 2015] Checking required binaries
[ok] samtools-1.2    /data/scratch/muliano/scripts/samtools-1.2
[ok] bwa-proovread   /data/scratch/muliano/scripts/proovread-master/bin/../ut
il/bwa
[ok] blastn-2.2.29   /usr/bin
[Tue Nov  3 17:56:10 2015] Running mode: sr
[Tue Nov  3 17:56:10 2015] Preparing long reads
#------------------------------------------------------------------------------#
perl -I/data/scratch/muliano/scripts/proovread-master/bin/../lib/ /data/scratch
/muliano/scripts/proovread-master/bin/SeqFilter --fasta --in pr-sample/read-lon
g/pr-sample.fq --line-width 80 --lower-case --out pr-sample/read-long/pr-sample
.masked.fa --phred-offset 33
Unknown option: in
#------------------------------------------------------------------------------#
[Tue Nov  3 17:56:10 2015] Read IDs don't look like proper PacBio subread IDs.
Falling back to running mode: sr-noccs
[Tue Nov  3 17:56:10 2015] Running task bwa-sr-1
[Tue Nov  3 17:56:10 2015] Indexing Long reads
#------------------------------------------------------------------------------#
/data/scratch/muliano/scripts/proovread-master/bin/../util/bwa/bwa-proovread in
dex pr-sample/read-long/pr-sample.masked.fa pr-sample/read-long/pr-sample.maske
d.fa 2>pr-sample/bwa-sr-1/pr-sample_bwa.log
#------------------------------------------------------------------------------#
#------------------------------------------------------------------------------#
Exited at 'main'
'./proovread', line 1280
Last call 'main::run_bwa'
'./proovread', line 856

END
I was checking the new SeqFilter and it does not have a parameter --in
Sounds to me the new SeqFilter version is not competible with proovread! Do you advice me on downloading an older one?
Thank you so much!

If you checked out proovread via the git clone --recursive it will automatically choose the right SeqFilter (v1.06). How did you install proovread?

I'm assuming, you have you been able to fix the problem. Feel free to reopen the issue if you haven't

Thanks thackl! I manage to get it working! Sorry for not answering sooner!


Incorrect marbles parsing in TestScheduler

RxJS version:
all <= 5.5.10
Code to reproduce:
https://stackblitz.com/edit/jasmine-testing-k1q6mh?file=src%2Fmerge.spec.ts
Expected behavior:
Expected $[3].frame = 40 to equal 70 - should not be thrown,
while parsing marbles, parenthesis should not increase asserted frames
cold('x-(xy)-x') where X [0f] - [1f] (xy) [2f] - [3f] x [4f]
Actual behavior:
it('why is this failed?', function () {
const one$ = cold('x-x-x');  - length: 4 frames * frameTimeFactor = 40
const two$ = cold('--y--'); - length: 4 frames * frameTimeFactor = 40
expect(one$.merge(two$)).toBeObservable(cold('x-(xy)-x'));  - on parsing the last frame, grouping is ignored and it compiles to 7 frames (each token as frame)
});
Additional information:

Please see #3581. The characters covered by the synchronous group count as actual frames. The commit mentioned in that issue introduced an error to the documentation.

Thanks, @cartant . But how can i test such a case using marbles? single emission after grouped
it('should not failed', function () {
const one$ = cold('x-x-x');
const two$ = cold('--y--');
expect(one$.merge(two$)).toBeObservable(cold('x-(xy)-x'));
});

You just need to space things out a bit by using more - characters. For padding, so to speak.

Ah, got it,
const one$ = cold('x-x----x');
Thanks a lot


pkg_resources.DistributionNotFound: The 'dirsync' distribution was not found and is required by wheel2deb

Running the command: wheel2deb --map attrs=attr
Is producing the following output:
Traceback (most recent call last):
File "/usr/bin/wheel2deb", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 3254, in
def _initialize_master_working_set():
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 3237, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 3266, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 584, in _build_master
ws.require(requires)
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 901, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/init.py", line 787, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'dirsync' distribution was not found and is required by wheel2deb

Figured this out.  Had to build dirsync from source, because we don't use pip to install packages - we use deb packaging.
Build debian package for dirsync here: https://github.com/tkhyn/dirsync
Might be something to include in the README file about the dependency on dirsync.


Having trouble running a simple read register example

Hi I was wondering if you can see why I can't get the following example to work.
I get the error
ExceptionResponse { function: 3, exception: GatewayTargetDevice }
pub fn main() {

    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let socket_addr = "<IP_ADDRESS>:502".parse().unwrap();

    let task = tcp::connect(&handle, socket_addr).and_then(|ctx| {

        ctx
            .read_holding_registers(0x16, 2)
            .and_then(move |data| {
                println!("Response is '{:?}'", data);
                Ok(())
            })
    });
    core.run(task).unwrap();
}

I know the ip code is correct as the following Python code works
c = ModbusClient()
c.host("<IP_ADDRESS>")
c.port(502)
c.unit_id(1)
c.debug(False)
c.open()

regs = c.read_holding_registers(0x16, 2)

if regs:
    print(regs)
    lsb = regs[0]
    msb = regs[1]
    print (msb << 16) | lsb
else:
    print("read error")

c.close()

What could be the issue here ?
Thanks

Maybe you need to switch the unit/slave id of the client context to 1 like you did in your Python code?
ctx.set_slave(Slave::from(1))

See also: trait SlaveContext
This is needed if the TCP device acts as a gateway. Otherwise the reserved unit id = 0xFF is used as the default for directly accessing the TCP device.

Once the slave/unit id is set it is used for all subsequent requests.

Thanks that was it.
I didn't replicate that bit from Python as it was not necessary to have it for the Python code. It must default to slave id 1.
Thanks

Feedback is always welcome.

It would be really handy to have this documented in the TCP example, even if just a comment:
// If the device acts as a gateway, set the unit ID to 1:
// ctx.set_slave(Slave::from(1))
Took me quite a while to figure out why my Rust version wasn't working when porting a client from Go's goburrow/modbus, which also sets the unit ID as the Python library does and didn't need this configuration.


Better comparison images

Please consider adding comparison images like in this article https://wackoid.com/game/10-pictures-that-show-why-crt-tvs-are-better-for-gaming/
Images in this article clearly shows the final rendering of image on CRT. These shaders in your repo should show something similar imo.

This is a good idea - I've been hesitant to use images that aren't either mine or public domain as promotional images (not sure what the legality is, even though this is a free thing), but I'll see if I can come up with some good examples!


ImportError

Hello,
When I try to import jpegio I receive the following error all the time:
>>> import jpegio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bertalan/anaconda3/envs/test/lib/python3.6/site-packages/jpegio-0.2.1-py3.6-linux-x86_64.egg/jpegio/__init__.py", line 7, in <module>
    from .decompressedjpeg import DecompressedJpeg
ImportError: /home/bertalan/anaconda3/envs/test/lib/python3.6/site-packages/jpegio-0.2.1-py3.6-linux-x86_64.egg/jpegio/decompressedjpeg.cpython-36m-x86_64-linux-gnu.so: undefined symbol: jpeg_write_coefficients

I have the following specifications:

Ubuntu 18.04
Python 3.6
Conda as dependency manager

I tried installed with the wheel and the setup.py install aswell but neither worked. Could you help me with this please? Thanks!

I recommend you to install by compiling: 'python setup.py install' In which direcotory have you tried importing the package?

I installed with "python setup.py install" in the /tmp directory. Could that have caused problems? It still does not work

@wowpocak
I've fixed the settings for linux, and uploaded the wheels.
Thanks for letting me know this error.


[OIDC] claims in ID Token

Even when an Access Token is delivered to the client we should still give our customers the option to represent those claims into the ID Token. This because a lot of software is actually not spec compliant.
This relates to https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

[ ] Create a Toggle on the client to assert the info to the ID Token

Relates to #939

Broken Software as examples

https://oauth2-proxy.github.io/oauth2-proxy/
https://www.cloudflare.com/en-gb/teams/access/


Fix path to CorsixTH app

Fixes https://github.com/caskroom/homebrew-cask/issues/12159

Thank you for the fix. Maybe it is also better to add additionally:
app 'CorsixTH/AnimView.app'
app 'CorsixTH/MapEdit.app'

Thank you for the contribution. It needed some fixes, so they were made in 7d2ef23f4d70fb45bea2beb427d9009710252b62. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.


[FEA] GDS Integration

Motivation
For many jobs running on spark-rapids, the ratio of computation to data movement is low, making them I/O bound. GPUDirect Storage (GDS) enables Direct Memory Access (DMA) between storage and GPUs, with increased bandwidth and lower latency, thus could potentially reduce file I/O overhead and increase overall job performance.
Goals

Integrate GDS and the cuFile API into spark-rapids.
Support reading input data and writing output data through GDS.
Support storing Spark temporary data using GDS.
Benchmark GDS performance with spark-rapids and provide recommendations on when to use GDS.

Non-Goals

GDS/cuFile is currently distributed as a user library and a kernel module, and requires installing MOFED and a few third-party libraries. In the future GDS may become part of the CUDA driver and the CUDA toolkit. The exact distribution mechanism is beyond the scope of this document.
For distributed filesystems, GDS currently supports Lustre, NFS, and WekaFS, which are not commonly used for storing data for Spark jobs. The initial integration will not focus on distributed filesystem support.
In a multi-node environment, GDS can write to and read from a remote storage server through NVMe-oF. This may be an alternative to the current UCX-based shuffle plugin, but probably not a full replacement.

Assumptions
In a deployment environment, we assume the user has correctly set up NVMe/NVMe-oF support for GDS, and installed the cuFile kernel module and the cuFile user library.
Risks

Until the final distribution mechanism is sorted out, spark-rapids with GDS may add extra complexity to the deployment process.
Depending on the hardware and software stack, and the particular Spark job, GDS may not provide a significant performance boost.

Design
This blog post provides a good overview of GDS. There is some public documentation.
For spark-rapids, integrating with GDS can be roughly considered along two dimensions: the type of data, and the type of storage.
A Spark job may deal with these types of data involving disk storage:

Input data. This is the data a Spark job reads from disk for processing, typically in CSV or Parquet format, and usually of large size.
Output data. This is the data a Spark job writes out. For an analytical query, the output size may be very small, but for data transformations (e.g. converting from CSV to Parquet) the output volume can be considerable.
Shuffle data. For many jobs, between the “map” and the “reduce” phases, the whole intermediate dataset needs to be redistributed across the whole cluster (“shuffled”). The default Spark shuffle manager writes all partitions to disk, while the spark-rapids shuffle plugin tries to keep buffers in the GPU.
Spilling. When a dataset cannot fit in memory, a portion may be spilled to disk. In external sorting, data is spilled to disk and read back in during merge sort. For the spark-rapids shuffle plugin, GPU buffers may be spilled to system memory or disk.

Storage can be accessed in several ways:

Local storage. These are NVMe drives attached to the local host, maybe in a RAID 0 configuration. Different PCIe switches may provide different affinity for each GPU, but as a first order of approximation, we can consider a single filesystem.
NVMe-oF. A storage server attached to the network (Ethernet, InfiniBand, or Fibre Channel) can be accessed using NVMe over fabrics.
Distributed filesystems. These provide a file system abstraction over remote storage. GDS currently supports Lustre, NFS, and WekaFS.

Here we can see how these two dimensions interact:

Data Type
Local storage
NVMe-oF
Distributed filesystem

Input/Output
Not suitable for “production” use, demo/benchmarks only
Needs storage server
Future

Shuffle
Single-node only, or with UCX on top?
Needs storage server; alternative to UCX?
Future

Spilling
Should work in general
May be overkill
Future

We should start with local storage since it is the easiest to set up. Possible first steps:

Input/output data on local storage. Since input data tends to have the biggest size, optimizing the I/O here may provide a big performance boost. It should be relatively easy to implement as only the readers/writers need to be changed to use the cuFile API. The main drawback is that in a real user environment the data is unlikely to fit on a single node, so this is only useful for initial demos and benchmarking.
Shuffle data on local storage. Spark’s default sort-based shuffle now has a ShuffleDataIO interface that can be overridden by passing the configuration spark.shuffle.sort.io.plugin.class. A new class can be implemented on top of the cuFile API. See blog post, JIRA, and SPIP. The drawback again is that this is single-node only.
Spilling to local storage. The easiest way to do this is to change the spilling mechanism in the spark-rapids shuffle plugin to spill directly to NVMe using the cuFile API.

At this point it is hard to predict which approach would provide the biggest benefit, so they probably should be tried in parallel.
Alternatives Considered
We may want to set up a distributed filesystem (e.g. NFS) on a storage server and implement everything on top of that. This would make the implementation production ready. But this may be a complex process and the performance may suffer, so it is higher risk as a first step.
Tasks
These are the initial list of tasks. May be modified or expanded later.

[x] CMake option to link to cuFile (https://github.com/rapidsai/cudf/pull/6847)
[x] JNI wrapper for cuFile (https://github.com/rapidsai/cudf/pull/6940)
[x] Support shuffle manager spilling to disk via cuFile (#1313)
[x] Fix "No such file or directory" issue (#1627)
[x] Benchmark cuFile-based shuffle manager spilling on DGX-2
[x] Benchmark cuFile-based shuffle manager spilling on Dell R7525
[x] Enable GDS in CI/CD
[x] Improve small buffer spilling performance #2295
[x] Test GDS store and buffer classes
[x] Documentation issue #2070, PR #2387
[x] Make GDS read/write 4KB-aligned (https://github.com/rapidsai/rmm/issues/762, https://github.com/rapidsai/cudf/pull/8266, https://github.com/rapidsai/cudf/pull/8301, #2460)

Closing this, there are a few followup issues that will be tracked separately: #2492 #2504 #2592 #2593

@rongou can we create an issue with the epic label for the follow up issues?


Define desired characteristics of server code from OpenAPITools generator

Environment Details

Helidon Version: 2.x, 3.x
Helidon SE or Helidon MP MP
JDK version:
OS:
Docker version (if applicable):

Problem Description
There are some characteristics of the server code from the OCI SDK code generator--or good characteristics in principle, apart from the OCI SDK generator--that are desirable in what we would get from the OpenAPITools generator.
We will use this issue to describe:

What are those characteristics and why is each useful and important?

For each, can we achieve it with the current generator and its options?

If not, what additions or changes to the generator would fill the gap? (new or changed template, new or expanded command-line option, etc.)

From this list (which can evolve over time) we can choose what to work on in what order as separate issues unto themselves.

As an example. @trentjeff has mentioned that the OCI SDK code generator creates abstract classes which developers then extend.
The existing OpenAPITools JavaJaxRS/spec generator (which is the one we have customized for Helidon) can generate either classes (not abstract) or interfaces, based on the interfacesOnly property which defaults to false.

What, if anything, could be improved about the code in the generated classes?

One possible enhancement could be to add an option to generate an abstract class instead of a concrete one. How useful and important would that be?

I do think generating the abstracts is a great option/alternative to the interfaces; it would allow default impls to be tucked into the base.
Furthermore, what I envision here is that there will be different mustache file "overlays" associated with a particular template name.  Templates could be "interfaceOnly" or "abstractsOnly", but could also allow us or our consumers to create extensions to these, most notably the "astractsOnly'.  An extension would mean only "overlaying" certain mustache files over the base template and giving it a new name (e.g., "helidon-mp" or "helidon-mp-oci", etc.).
A key driver for this is would be security, where we would expect certain key/principal/identity collateral is picked up on the client-side dictated by the particular named template profile, and then on the server-side integrated with the "proper' security providers.  Security collateral is just one form of context propagation, but generally speaking, we should support tracing context propagation as well to further allow for a customizable/extensions mechanism for our customers to use for their cases as well.

Is there really an advantage to generate abstract classes over concrete, non-final classes with simple no-ops? I like the idea of being able to compile and run the generated code first, and then override its behavior via subclassing/overriding. Being able to generate interfaces may be useful as well in some cases.

I do think generating the abstracts is a great option/alternative to the interfaces; it would allow default impls to be tucked into the base.

As I mentioned above, the generator on which the Helidon support is based already generates either interfaces or classes based on the interfacesOnly option. The generated classes are concrete, not abstract, and also not final. Hence my earlier question: is having the generated classes be abstract instead of concrete important enough to add an option to the code or use a custom template?
Santiago makes a very good related point about a concrete, non-final class with a no-op or trivial implementation having the advantage of being immediately buildable and runnable.

Furthermore, what I envision here is that there will be different mustache file "overlays" associated with a particular template name. Templates could be "interfaceOnly" or "abstractsOnly", but could also allow us or our consumers to create extensions to these, most notably the "astractsOnly'. An extension would mean only "overlaying" certain mustache files over the base template and giving it a new name (e.g., "helidon-mp" or "helidon-mp-oci", etc.).

"Overlays" and "extensions" are not terms used by the OpenAPITools generator documentation.
The generator supports three ways to adjust the generation at generation-time, what their website refers to as:

templating (https://openapi-generator.tech/docs/templating/) The user specifies a directory (via the --template-dir option) or adds a JAR on the runtime class path of the generator. Either one contains mustache files with the same names as files the generator/library combination already uses, the the generator prefers those vs. the ones packaged with the generator. Users can affect the output for templates the generator/library already uses, but cannot add new templates.

user-defined templates (https://openapi-generator.tech/docs/templating#user-defined-templates) The user provides a configuration file that can contain command-line options (such as --template-dir) plus a files section listing

custom generator (https://openapi-generator.tech/docs/templating#custom-generator-and-template) The user adds an entirely separate, custom generator (code and templates) to the class path and runs the OpenAPITools code, choosing that custom generator using the --generator option.

IIUC, the templating approach might be sufficient for what you've described.
If there were a group of templates that needed customization in a coherent way for, say, OCI services, then customized versions of those templates could be gathered into a single JAR once and then used repeatedly and my many developers, presumably, for generating any number of services. This is the easiest approach to test and to make available to users.
Someone (presumably Helidon) could build, document, and publish one or more JAR file containing customized templates tuned to particular developer groups or use cases: OCI, for example.

IIUC, the templating approach might be sufficient for what you've described.

+1

if there were a group of templates that needed customization in a coherent way for

I had assumed (maybe wrongly) that this will be inevitable, especially on the client-side, in order to pick up the propagated context including any security collateral.

I would like this issue to focus on the server-side code generation simply because the client vs. server side generator code and templates are separate when viewed from the point of view of the OpenAPITools project (although certainly related from our point of view), and so changes to the client vs. server generation would most likely be in separate PRs driven from separate issues.

I had assumed (maybe wrongly) that this will be inevitable, especially on the client-side, in order to pick up the propagated context including any security collateral.

Pretty soon we need to drill down to the next level of detail. Can you add snippets of example server code (not templates) here to show how code that works the way you have in mind would ultimately look?

What, if anything, could be improved about the code in the generated classes?

Indentation and general formatting of the code is poor. We can't control everything, but we should make the generated code more consistent with our rules. Current rules for JAX-Rs seem inconsistent, for example Api code and Model code is formatted very differently. This will likely require more Helidon-specific templates.

One possible enhancement could be to add an option to generate an abstract class instead of a concrete one. How useful and important would that be?

The concrete classes generated by the tool seem fine to me, other than perhaps the BV annotations, which perhaps should not be generated by default.

RE: BV annotations. We could turn those off by default for the helidon library adding a line to the Helidon-specific Java code:
https://github.com/OpenAPITools/openapi-generator/blob/21c399f2b88e2ba824648d749025880ed5359cd3/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/JavaJAXRSSpecServerCodegen.java#L216-L223
Something like
additionalProperties.computeIfAbsent(BeanValidationFeatures.USE_BEANVALIDATION, key -> "false");

another request here is to provide an option to generate either sync or async clients, or both.

Again, let's focus this issue on desired characteristics of generated server code.
On the client side, we have two broad categories covered by other issues or by other work already completed:

For clients connecting to OCI services we want to encourage developers to use the OCI CDI extension. Yes, this is MP-only but as I understand it that's the majority of use cases.
For clients connecting to non-OCI services we have two open issues:
a.  #4012 to cover Helidon MP
b. #4022 This work needs to be revived but already generates both sync and async support.


Fix/allow nest v6 in peer deps

Allows to use package in nest@v5 and in nest@v6
You can verify version range here:
https://jubianchi.github.io/semver-check/#/^5.1.0 || ^6.0.3/5.1.1

You can ensure both versions are supported here
https://jubianchi.github.io/semver-check/#/^5.1.0 || ^6.0.3/5.1.1

Pull Request Test Coverage Report for Build 221

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.101%

Totals

Change from base Build 220:
0.0%

Covered Lines:
151

Relevant Lines:
151

💛  - Coveralls

Sorry, removed by mistake


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-source-version-target/pull/42 is merged into live branch.
Auto archive content to https://github.com/VSC-Service-Account/docs-archive-test-source-version-target.git

Docs Build status updates of commit 8cf5b49:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

versioningArchiveSourceFolder/TOC.yml
:white_check_mark:Succeeded
View (sql-server-2014 || azuresqldb-current || azuresqldb-mi-current || azure-sqldw-latest || >= aps-pdw-2016 || >= sql-server-2016 || >= sql-server-linux-2017 || sql-server-previousversions || sqlallproducts-allversions)

versioningArchiveSourceFolder/docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 8cf5b49:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

versioningArchiveSourceFolder/TOC.yml
:white_check_mark:Succeeded
View (sql-server-2014 || azuresqldb-current || azuresqldb-mi-current || azure-sqldw-latest || >= aps-pdw-2016 || >= sql-server-2016 || >= sql-server-linux-2017 || sql-server-previousversions || sqlallproducts-allversions)

versioningArchiveSourceFolder/docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Panics on OSX: unable to generate a flame graph

First of all, thanks so much for adding support to dtrace and OSX!
I'm trying to use cargo flame graph on bench output on OSX.  This is how I run it:
sudo cargo flamegraph --exec="target/release/bench-aba573ea464f3f67"
(where bench-aba... is the executable produced by running cargo bench first)
The error:
unpack delta u64s       time:   [73.363 ns 73.823 ns 74.303 ns]
                        change: [-22.503% -20.920% -19.423%] (p = 0.00 < 0.05)
                        Performance has improved.

dtrace: pid 87448 has exited
thread 'main' panicked at 'unable to generate a flamegraph from the collapsed stack data: Io(Custom { kind: InvalidData, error: StringError("No stack counts found") })', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

NOTE:  this is how I used to run dtrace to get a flame graph:
sudo dtrace -c './target/release/bench-2022f41cf9c87baf --profile-time 120' -o out.stacks -n 'profile-997 /pid == $target/ { @[ustack(100)] = count(); }'
~/src/github/FlameGraph/stackcollapse.pl out.stacks | ~/src/github/FlameGraph/flamegraph.pl >rust-bench.svg

I did not add --profile-time this time but I don't think that would make a difference.

Hey @velvia, does this error still happen with the new standalone flamegraph binary instead of passing --exec... to cargo-flamegraph?
What operating system version are you using?
Is the cargo-flamegraph.stacks file totally empty? If not, could you please paste it here?

@spacejam 10.13.6, and there's no cargo-flamegraph.stacks file... unless it outputs in a different dir.
Sorry what do you mean by "standalone flame graph binary"?

I had this issue as well, but after updating to the latest (v0.1.12) version of flamegraph this worked fine for me.
@velvia The newer releases additionally install a binary called flamegraph.

Yeah, seems the latest version is working now.   I can run sudo flamegraph bench-..... etc. and it generates a flamegraph.
I do see errors like this, but I think can close it.
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0x63f9762928206260) in action #2
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0x2545a7a2) in action #2
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0x2545a7a2) in action #2

Same error still exists with v0.1.13, and OSX version is Mojave 10.14.
After reporting below errors, target executable ends but not flamegraph generated.
Can I reopen this PR ?
...
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0x762e73ea) in action #2
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0x33f087b3) in action #2
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0xfffffffe) in action #2
dtrace: error on enabled probe ID 1 (ID 34: profile:::profile-997): invalid address (0xfffffeff) in action #2
thread 'main' panicked at 'unable to collapse generated profile data: Custom { kind: InvalidData, error: StringError("stream did not contain valid UTF-8") }', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Howdy.
I'm receiving this error error within a container running on MacOS Mojave (via multiple runs on 0.1.13 and the current git/master version):
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.119 MB perf.data (8 samples) ]
writing flamegraph to "flamegraph.svg"
thread 'main' panicked at 'unable to generate a flamegraph from the collapsed stack data: Io(Custom { kind: InvalidData, error: "No stack counts found" })', src/libcore/result.rs:1165:5

Can we reopen this or am I doing something awry? Thanks.