Fatal Error - Problematic frame libc.so.6+0x15c6ff - Server Crash

I am facing an issue where both Pinot servers are not restarting and they are keep on crashing with following error. I am using latest image. Any one came across this?
 [Times: user=0.02 sys=0.00, real=0.00 secs]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f104649b6ff, pid=1, tid=0x00007ee665d06700
#
# JRE version: OpenJDK Runtime Environment (8.0_282-b08) (build 1.8.0_282-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.282-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x15c6ff]
#
# Core dump written. Default location: /opt/pinot/core or core.1
#
# An error report file with more information is saved as:
# /opt/pinot/hs_err_pid1.log

my-pinot-server-0 server  [Times: user=0.08 sys=0.00, real=0.02 secs]
my-pinot-controller-0 controller 2021/01/26 22:17:09.409 WARN [CallbackHandler] [ZkClient-EventThread-29-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Callback handler received event in wrong order. Listener: org.apache.helix.controller.GenericHelixController@362617cf, path: /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES, expected types: [INIT] but was CALLBACK
my-pinot-server-1 server 2021/01/26 22:17:09.588 WARN [ZkBaseDataAccessor] [ZkClient-EventThread-18-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Fail to read record for paths: {/pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7fdbc2b8-d50c-43e0-8aae-8f81149ff9f6=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ebfe4780-7d65-42a0-9293-8de8be680b52=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5cae61b1-c190-4ba4-8d75-2f55fbef3204=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b3a4690d-8f0b-49f7-a950-6fd56746760c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0febb043-2ddb-44b6-8637-ac9ec8e991c4=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/08aa0bbe-ddbc-4a40-8e4b-a94faee38d4c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4c94c196-7ed7-46cc-9b48-a7d3928df6c5=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f8d49a81-2834-4a12-9908-e8f52f6a8b9b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2eb95020-540c-46e7-b18b-56232d5079ce=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ddc77c89-593b-4278-954f-6d0aad4bba4a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/09a788d4-f94b-4172-a7b5-ed6df22523b7=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b12423f6-22ba-46cb-a23a-84f20dbb7bb8=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b8cb57cc-db6c-414a-a97e-b4fd2147ce14=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/c70e5415-1520-485d-9eb7-2d43940422a3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/352ead98-9e5d-4572-b4a9-224c7dff6a3d=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b0405375-5316-41ad-b134-ed55d2b54407=-101}
my-pinot-controller-0 controller 2021/01/26 22:17:09.600 WARN [CallbackHandler] [ZkClient-EventThread-29-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Callback handler received event in wrong order. Listener: org.apache.helix.controller.GenericHelixController@362617cf, path: /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES, expected types: [INIT] but was CALLBACK
my-pinot-server-0 server 2021-01-26T22:17:09.358+0000: 113.899: Total time for which application threads were

my-pinot-server-0 server  [Times: user=0.08 sys=0.00, real=0.02 secs]
my-pinot-controller-0 controller 2021/01/26 22:17:09.409 WARN [CallbackHandler] [ZkClient-EventThread-29-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Callback handler received event in wrong order. Listener: org.apache.helix.controller.GenericHelixController@362617cf, path: /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES, expected types: [INIT] but was CALLBACK
my-pinot-server-1 server 2021/01/26 22:17:09.588 WARN [ZkBaseDataAccessor] [ZkClient-EventThread-18-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Fail to read record for paths: {/pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7fdbc2b8-d50c-43e0-8aae-8f81149ff9f6=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ebfe4780-7d65-42a0-9293-8de8be680b52=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5cae61b1-c190-4ba4-8d75-2f55fbef3204=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b3a4690d-8f0b-49f7-a950-6fd56746760c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0febb043-2ddb-44b6-8637-ac9ec8e991c4=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/08aa0bbe-ddbc-4a40-8e4b-a94faee38d4c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4c94c196-7ed7-46cc-9b48-a7d3928df6c5=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f8d49a81-2834-4a12-9908-e8f52f6a8b9b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2eb95020-540c-46e7-b18b-56232d5079ce=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ddc77c89-593b-4278-954f-6d0aad4bba4a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/09a788d4-f94b-4172-a7b5-ed6df22523b7=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b12423f6-22ba-46cb-a23a-84f20dbb7bb8=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b8cb57cc-db6c-414a-a97e-b4fd2147ce14=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/c70e5415-1520-485d-9eb7-2d43940422a3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/352ead98-9e5d-4572-b4a9-224c7dff6a3d=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b0405375-5316-41ad-b134-ed55d2b54407=-101}
my-pinot-controller-0 controller 2021/01/26 22:17:09.600 WARN [CallbackHandler] [ZkClient-EventThread-29-my-pinot-zk-cp-zookeeper.logging.svc.cluster.local:2181] Callback handler received event in wrong order. Listener: org.apache.helix.controller.GenericHelixController@362617cf, path: /pinot-quickstart/INSTANCES/Server_my-pinot-server-1.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES, expected types: [INIT] but was CALLBACK
my-pinot-server-0 server 2021-01-26T22:17:09.358+0000: 113.899: Total time for which application threads were

my-pinot-controller-0 controller 2021/01/26 22:17:12.039 WARN [ZkBaseDataAccessor] [HelixController-pipeline-task-pinot-quickstart-(83ee1db3_TASK)] Fail to read record for paths: {/pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/51a431e9-c0e1-4e08-9bcb-aee747608526=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f9005198-fe85-4cad-84e8-0df918de95d9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ef3e0a42-eee4-43a4-bb11-bd1878937e2c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2fd3aeea-91d8-446d-b87f-eeb3d99e24c9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/03239839-70d8-49ed-84eb-6d9d4bc3b777=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d7c99ffe-7a4d-433b-a265-cf8c9fba6a5f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d299feba-1781-407e-a7b3-83287fbd0997=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/68902832-2e61-4e6a-b249-e0e74711d493=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/084390ed-cccd-4171-b4c1-45c2f43ddc1a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/53c3065c-60e3-4355-ab33-9f32221c5407=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/46f7ae44-ee3d-45c0-8781-6cedc67ea518=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ba4e44c4-15d1-46a7-ac99-3f4fd11db97f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/dd3e8c08-e914-4245-8857-3d1229573c35=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/95ad2084-572f-4651-b009-1f3eaab73e6b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/cc5bea58-9618-4746-9a6c-a6b8e5afdfaa=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3491cf67-e305-4767-9d55-0963f9ffdf00=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/c7dca37a-e4d6-4fbf-a244-ec5b92724c9e=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b224f8f5-ea43-419a-a3af-11dace5e3f16=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ae7c5ede-f7ec-45bb-a095-97210c6a7932=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/15a7fbcc-48b5-4300-9338-a0b009151e9e=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f46c6152-858f-44f6-8658-f7c7540915f5=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7a6a008a-33a2-4b08-9aac-db2fd0c00396=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7819229e-21af-4760-9ce3-c38e446c1e14=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5dcd8621-f658-4c49-be47-41aea30e9cb4=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/92519c36-bcfb-4501-8dbb-0702ebdfd708=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5fa1b752-39e8-4563-847e-4eaef3c3d5b0=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/74263ff4-734d-4529-966c-f0cb0927593f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/98bb3b99-80d8-40bb-bdb6-d34f0b5e1090=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39114365-1976-42ab-882d-e729eb70c143=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/86c29e7a-c24d-46f1-9efb-865b02b8999a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/bc02072d-68db-4264-acb6-e6ded758a74a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/aec1490b-4a0f-4d66-aad7-f2801b172b65=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d894e3b1-e597-484f-a748-96a470c93f93=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/1b1ec9f0-c17f-44f7-b6a1-26c0c141892f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/8f0d8d0a-ec3a-4b11-bbf8-f44e0b611d3f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/230e18fe-135b-4892-ac34-ae7909874224=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3d64a6bb-5e6c-4f72-87eb-ac295cb7c0e3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4e0b1fb2-f514-4350-92ac-2162c408f947=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b110753b-49e3-42d8-8a92-f635247a5d32=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3891485f-621c-4a62-a702-4de7b9cda0ca=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b221af1a-3704-4290-a980-4e6fac076d08=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5b970ff8-8f17-4518-9ffc-7ff72a0bc52b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7401939f-83a1-433b-9a4b-801e8b110b49=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/16a027cf-5c09-4b5f-9030-8bc8f0afcded=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/1ef817b6-21cc-48ae-bd16-ed2ad2e80b6d=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/8e9f37bf-25e0-4086-8401-df0f73850a6b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/88f453a1-eca9-4b2c-9e4f-87e88da6e4ed=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d0d42bf9-3b12-4686-8c7d-cd7bde6284cc=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4f2526dc-cdf6-4035-b1b6-bef9f8871583=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2b020fac-6c46-4eb2-9802-1cb7bd7c586b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/11b63a38-99d9-442c-9eca-56f7d427c9a1=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/372cec23-e89b-421d-b611-b9bd35ed6bb3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5a0aa3ae-d134-47e1-8fae-53aa0d70ee99=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/aec9d3ad-f1e9-4429-b031-1207534e9dff=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/fd9592c2-22e9-4536-a8ef-4d4e1eab6d5f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0c36d8f7-7905-48a7-befe-7f48693f4c17=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0e31dca5-4234-4842-a5ac-b44ccd01d1cb=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d998d2e5-1796-42be-8848-9154d0d0be2f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3e201c8c-f8cb-431c-9e10-ab7da5a03eef=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7bb908de-8c97-4cc7-8499-440d2e7ce19c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/06af6769-999b-4aa9-b1ec-4d3f063eb998=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/84eb9eb3-3ff4-4c47-9bb4-daa685ff7290=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5f3a394a-0f9e-410b-ab9f-fd6989052588=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/42c83d12-35b8-4999-ace6-c51a9c15f5da=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/53e12a60-c891-4182-a8c6-a04cac8f7e9c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39ef8da1-1fd3-4de7-a150-1962ccda4194=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39cb56e1-2dca-4c72-9bb6-ad98e83bd6fe=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/88580d08-3d66-4c48-8678-8d2879687ddc=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5b1e6f1e-51d5-438d-a207-3af761fe960c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ad69603f-3ae7-43b0-9449-2f732c8acdfb=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5514c26b-2d5e-47a3-839f-3c5b98303bc9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/25c2728e-73eb-4ebe-b2d4-e61708348652=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0b22e1da-632b-430c-be22-cc0c46ad0a75=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/dfd7e352-76e0-4a24-9294-84b72106d709=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/bea0dc31-8f14-4c54-8097-64f11b0a0f22=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/56805ab0-d620-401f-a6de-d2890709151d=-101}
my-pinot-server-0 server 2021-01-26T22:17:11.909+0000: 116.450: Total time for which application threads were stopped: 0.0134050 seconds, Stopping threads took: 0.0001936 seconds

my-pinot-controller-0 controller 2021/01/26 22:17:12.039 WARN [ZkBaseDataAccessor] [HelixController-pipeline-task-pinot-quickstart-(83ee1db3_TASK)] Fail to read record for paths: {/pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/51a431e9-c0e1-4e08-9bcb-aee747608526=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f9005198-fe85-4cad-84e8-0df918de95d9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ef3e0a42-eee4-43a4-bb11-bd1878937e2c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2fd3aeea-91d8-446d-b87f-eeb3d99e24c9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/03239839-70d8-49ed-84eb-6d9d4bc3b777=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d7c99ffe-7a4d-433b-a265-cf8c9fba6a5f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d299feba-1781-407e-a7b3-83287fbd0997=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/68902832-2e61-4e6a-b249-e0e74711d493=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/084390ed-cccd-4171-b4c1-45c2f43ddc1a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/53c3065c-60e3-4355-ab33-9f32221c5407=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/46f7ae44-ee3d-45c0-8781-6cedc67ea518=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ba4e44c4-15d1-46a7-ac99-3f4fd11db97f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/dd3e8c08-e914-4245-8857-3d1229573c35=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/95ad2084-572f-4651-b009-1f3eaab73e6b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/cc5bea58-9618-4746-9a6c-a6b8e5afdfaa=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3491cf67-e305-4767-9d55-0963f9ffdf00=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/c7dca37a-e4d6-4fbf-a244-ec5b92724c9e=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b224f8f5-ea43-419a-a3af-11dace5e3f16=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ae7c5ede-f7ec-45bb-a095-97210c6a7932=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/15a7fbcc-48b5-4300-9338-a0b009151e9e=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/f46c6152-858f-44f6-8658-f7c7540915f5=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7a6a008a-33a2-4b08-9aac-db2fd0c00396=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7819229e-21af-4760-9ce3-c38e446c1e14=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5dcd8621-f658-4c49-be47-41aea30e9cb4=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/92519c36-bcfb-4501-8dbb-0702ebdfd708=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5fa1b752-39e8-4563-847e-4eaef3c3d5b0=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/74263ff4-734d-4529-966c-f0cb0927593f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/98bb3b99-80d8-40bb-bdb6-d34f0b5e1090=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39114365-1976-42ab-882d-e729eb70c143=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/86c29e7a-c24d-46f1-9efb-865b02b8999a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/bc02072d-68db-4264-acb6-e6ded758a74a=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/aec1490b-4a0f-4d66-aad7-f2801b172b65=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d894e3b1-e597-484f-a748-96a470c93f93=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/1b1ec9f0-c17f-44f7-b6a1-26c0c141892f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/8f0d8d0a-ec3a-4b11-bbf8-f44e0b611d3f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/230e18fe-135b-4892-ac34-ae7909874224=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3d64a6bb-5e6c-4f72-87eb-ac295cb7c0e3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4e0b1fb2-f514-4350-92ac-2162c408f947=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b110753b-49e3-42d8-8a92-f635247a5d32=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3891485f-621c-4a62-a702-4de7b9cda0ca=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/b221af1a-3704-4290-a980-4e6fac076d08=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5b970ff8-8f17-4518-9ffc-7ff72a0bc52b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7401939f-83a1-433b-9a4b-801e8b110b49=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/16a027cf-5c09-4b5f-9030-8bc8f0afcded=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/1ef817b6-21cc-48ae-bd16-ed2ad2e80b6d=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/8e9f37bf-25e0-4086-8401-df0f73850a6b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/88f453a1-eca9-4b2c-9e4f-87e88da6e4ed=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d0d42bf9-3b12-4686-8c7d-cd7bde6284cc=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/4f2526dc-cdf6-4035-b1b6-bef9f8871583=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/2b020fac-6c46-4eb2-9802-1cb7bd7c586b=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/11b63a38-99d9-442c-9eca-56f7d427c9a1=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/372cec23-e89b-421d-b611-b9bd35ed6bb3=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5a0aa3ae-d134-47e1-8fae-53aa0d70ee99=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/aec9d3ad-f1e9-4429-b031-1207534e9dff=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/fd9592c2-22e9-4536-a8ef-4d4e1eab6d5f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0c36d8f7-7905-48a7-befe-7f48693f4c17=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0e31dca5-4234-4842-a5ac-b44ccd01d1cb=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/d998d2e5-1796-42be-8848-9154d0d0be2f=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/3e201c8c-f8cb-431c-9e10-ab7da5a03eef=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/7bb908de-8c97-4cc7-8499-440d2e7ce19c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/06af6769-999b-4aa9-b1ec-4d3f063eb998=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/84eb9eb3-3ff4-4c47-9bb4-daa685ff7290=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5f3a394a-0f9e-410b-ab9f-fd6989052588=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/42c83d12-35b8-4999-ace6-c51a9c15f5da=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/53e12a60-c891-4182-a8c6-a04cac8f7e9c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39ef8da1-1fd3-4de7-a150-1962ccda4194=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/39cb56e1-2dca-4c72-9bb6-ad98e83bd6fe=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/88580d08-3d66-4c48-8678-8d2879687ddc=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5b1e6f1e-51d5-438d-a207-3af761fe960c=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/ad69603f-3ae7-43b0-9449-2f732c8acdfb=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/5514c26b-2d5e-47a3-839f-3c5b98303bc9=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/25c2728e-73eb-4ebe-b2d4-e61708348652=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/0b22e1da-632b-430c-be22-cc0c46ad0a75=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/dfd7e352-76e0-4a24-9294-84b72106d709=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/bea0dc31-8f14-4c54-8097-64f11b0a0f22=-101, /pinot-quickstart/INSTANCES/Server_my-pinot-server-0.my-pinot-server-headless.logging.svc.cluster.local_8098/MESSAGES/56805ab0-d620-401f-a6de-d2890709151d=-101}
my-pinot-server-0 server 2021-01-26T22:17:11.909+0000: 116.450: Total time for which application threads were stopped: 0.0134050 seconds, Stopping threads took: 0.0001936 seconds

what changed?

what changed?

Nothing Changes it was running for 3 days without a hinch and suddenly keep crashing. I changed the memory from -Xms512M -Xmx4G to -Xms12G -Xmx12G and servers are up . Not sure what happened here..!! Also cannot get hold of coredmp or threaddmp as it is container. I may have to map /opt/pinot to some pvc.

Nothing Changes it was running for 3 days without a hinch and suddenly keep crashing. I changed the memory from -Xms512M -Xmx4G to -Xms12G -Xmx12G and servers are up . Not sure what happened here..!! Also cannot get hold of coredmp or threaddmp as it is container. I may have to map /opt/pinot to some pvc.

Anyways all the segments are in corrupted status..!!!  It seems I have to restore the server from backup again..!!!

Anyways all the segments are in corrupted status..!!!  It seems I have to restore the server from backup again..!!!

I reloaded the segments and the server is back online . Is there any way to speed up the catch up process from the kafka stream?

I reloaded the segments and the server is back online . Is there any way to speed up the catch up process from the kafka stream?

add more servers and once they catch up, shrink the cluster and rebalance..

add more servers and once they catch up, shrink the cluster and rebalance..

Thanks @kishoreg , The server did not recover. it went to bad state again and Pinot server crashed. I had to do the hard way delete and recreate.  What are the possibilities of server crash in Pino and what steps normally we can take to avoid this?

Thanks @kishoreg , The server did not recover. it went to bad state again and Pinot server crashed. I had to do the hard way delete and recreate.  What are the possibilities of server crash in Pino and what steps normally we can take to avoid this?

any logs that you can share.

any logs that you can share.

@kishoreg @fx19880617  , it crashed again and Pino server stopped consuming messaging and query started to give incorrect results.   This will  only happen when I recreate the table and try to catch up messages.

@kishoreg what could be the possible reasons the space is getting filled when I try to catch up messages from the stream? This will  only happen when I recreate the table and try to catch up messages.

Storage will be filled up naturally as the servers consume more records, and flush them to the disk. Can you please check the disk space left in your data directory?

Storage will be filled up naturally as the servers consume more records, and flush them to the disk. Can you please check the disk space left in your data directory?

@Jackie-Jiang Thanks it was 100% . I deleted some data from stream . But not sure why a full stream catch up takes more disk space that normal realtime consumption. From my understanding data size for three days retention on kafka should remain same whether we consume  in Pinot at one shot or consume in three long days.

@Jackie-Jiang Thanks it was 100% . I deleted some data from stream . But not sure why a full stream catch up takes more disk space that normal realtime consumption. From my understanding data size for three days retention on kafka should remain same whether we consume  in Pinot at one shot or consume in three long days.

Thanks for the suggestion @Jackie-Jiang , I will allocate more space. Also wondering whether it is possible to set the segment time based on the time field from kafka? So that segments will expire based on kafka time rather than Pinot segment created time. My retention is 3 days , the issue happens when I have to catch up entire 3 days messages at once and all the caught up segment  dates will have same date and will only expire after 3 days.

Thanks for the suggestion @Jackie-Jiang , I will allocate more space. Also wondering whether it is possible to set the segment time based on the time field from kafka? So that segments will expire based on kafka time rather than Pinot segment created time. My retention is 3 days , the issue happens when I have to catch up entire 3 days messages at once and all the caught up segment  dates will have same date and will only expire after 3 days.

@pabrahamusa Pinot is using the time column (should be the time field in kafka as well) value to expire the segment, instead of the segment creation time. The segment will still be created, but should be removed once the latest time value is older than the retention.

@Jackie-Jiang Thanks I will verify this and confirm .


Allow Info findings to be pushed to JIRA without SLA

Findings with an Info severity do not get an SLA. When creating new issues to push to JIRA, a findings SLA is used to set the due date on the JIRA issue. Since Info findings don't have an SLA, trying to add one results in an exception and the issue is not pushed. This added check just ignores that field if it is an Info finding.

I would expect the find.sla_deadline() to be None and we should check on that to be None and skip duedate setting in JIRA?
We should try to minimize internal logic in the JIRA code.

Not exactly sure how the internals of the Jira integration work exactly but I can tell you that I was getting a Python exception on info findings being pushed to Jira.  I mentioned this on a chat with Maffooch yesterday and I guess he listened :-)

The fact that it works, doesn't mean it's solved in the best place. To me it feels weird that the JIRA integration code needs to know about that Info findings don't have a sla deadline. Second weird is that the jira code and anyone who reads it needs to know that the get_number_severity method returns False or None (or zero?) for Info findings. Or does it return that for all findings without an sla deadline?
Apart from that if other integrations would also want to use a duedate / deadline field, thy would need to implement the same logic and we would have the same logic in multiple places (github integration, sla notifications, future bugtrackers, ...)
So what I am saying is that finding.sla_deadline() should return None if there is no deadline. The JIRA then only needs to do a simple ìf` wihtout knowing anything about the relationship between SLA's, severities, numerical severities, etc.

I believe this complies with Valtenjin's suggestion. Can adjust if that is not the case.

Better yes, thanks!


Can't parse key with '=' symbol

My toml file content is:
[module]
	"foo=bar" = "zzz"

and I have error: Expected """ but "=" found. Why?

Hey there! Thanks for reporting this. It's fixed in v2.3.2.


[Discussion] Auto weekly report for dubbo

I am a developer from Alibaba and I build a GitHub collaborate robot which is a framework to collaborate with GitHub projects.
Currently, this robot has a component to report weekly status of a repo as a issue, like this. This weekly report will summarize the basic data of the repo and overview of merged pull requests, pr reviews and new contributors which is very helpful to get the general picture of Dubbo.
This robot has basic services like data provider, event manager, GitHub request client, GitHub hook, web service and scheduler. But with weekly report function only, we don't need to have any access authority of the repo and the robot will only play as a community developer who knows the repo very well.
WDYT.

I am a developer from Alibaba and I build a GitHub collaborate robot which is a framework to collaborate with GitHub projects.
Currently, this robot has a component to report weekly status of a repo as a issue, like this. This weekly report will summarize the basic data of the repo and overview of merged pull requests, pr reviews and new contributors which is very helpful to get the general picture of Dubbo.
This robot has basic services like data provider, event manager, GitHub request client, GitHub hook, web service and scheduler. But with weekly report function only, we don't need to have any access authority of the repo and the robot will only play as a community developer who knows the repo very well.
WDYT.

Already deploy robot for Dubbo weekly report.

周报机器人罢工了，需要调整

周报机器人罢工了，需要调整@Frankzhaopku

对不起，由于我已经离开阿里了，目前这个机器人的部署已不再我的权力范围内了，我会尽快和社区沟通，看是否需要重新为 Dubbo 部署一个机器人


Intuition of the target_weight in the loss

Hello, thank you for the great code!
I like the simplicity of the loss, however I don't understand one specific case when:

the joint is not visible in the object patch AND there is a wrong prediction (FP), then the loss will be zero because the target_weight=0. Shouldn't one want to penalize such a case of FPs?

Why wouldn't you not use target_weight, then both FPs and FNs would be penalized which is good.

good idea!    If you make sure that patches don't include other objects, it noteceably improved my results. The reason it works better in their case because at least in case of MPII, the patches are given and they include several humans...

@anuar12  To be honest, your english level is so high that I can't understand what you write. You're great


Feat: Autogenerate sidebar labels

Description

Resolves https://github.com/withastro/starlight/discussions/1630
Now using a sidebar entry with the key slug to specify the file will dynamically pull in that file's title

TODOs

[ ] Do the test updates look alright? I added on to the current tests instead of breaking out into a separate one, but can do that if wanted
[ ] Changeset
[ ] Docs updates

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/sidebar.mdx
Source changed, localizations will be marked as outdated.

en
reference/configuration.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Wow! Very nice feature, it will greatly improve the DX!
I also faced this and it feels uncomfortable especially when the sidebar contains autogenerated groups and some manually added items. In this case, the autogenerated pages define their sidebar title in the Front Matter section. At the same time, the manual items should define it in the sidebar configuration.
This is also bad for i18n, because the labels for manually added items should be localized separately using the translations configuration.
Waiting for this to ship! 🚀

Thanks for diving in, @delucis , and feel free to run wild with any of my PRs anytime 😂
RE: usage in the sidebar guide, I think it's covered pretty well with what you've written. My only though overall for documentation is that it may be helpful to specify this is for files in src/content as "internal" could also be considered for thinks like assets, public files, and non-content collection pages.

My only though overall for documentation is that it may be helpful to specify this is for files in src/content as "internal" could also be considered for thinks like assets, public files, and non-content collection pages.

Yes, I also considered that. That’s why I used “internal docs pages”, but agree that being more explicit could make sense! Let me have a quick try.

LGTM!

I was just looking for this functionality this morning, perfect timing, and great work! Thank you 🙏


Add AsyncNinja

Pull Request Description
AsyncNinja project added with builds and tests on macOS, iOS (32bit and 64bit), tvOS.
AsyncNinja strongly relies on a type system with protocol oriented programming and nested generics.
Acceptance Criteria
To be accepted into the Swift source compatibility test suite, a project must:

[x] be an Xcode or swift package manager project
[x] support building on either Linux or macOS
[x] target Linux, macOS, or iOS/tvOS/watchOS device
[x] be contained in a publicly accessible git repository
[x] maintain a project branch that builds against Swift 3.0 compatibility mode
and passes any unit tests
[x] have maintainers who will commit to resolve issues in a timely manner
[x] be compatible with the latest GM/Beta versions of Xcode and swiftpm
[x] add value not already included in the suite
[x] be licensed with one of the following permissive licenses:

BSD
MIT
Apache License, version 2.0
Eclipse Public License
Mozilla Public License (MPL) 1.1
MPL 2.0
CDDL

[x] pass ./check script run

Ensure project meets all listed requirements before submitting a pull request.

@swift-ci Please test source compatibility

Looks good. Thanks!


Package size

Hey @grubersjoe, thank you for the great package!
Do you have any plans to reduce the package size? According to Bundlephobia, the size is over 40 KB. Chroma-js alone takes up 14.5 KB, which is quite a lot. Once again, thank you for your work! Cheers!

Hey @xanderim. Thanks for the hint, improving the bundle size is definitely something I'd also like to do. I'll look into it when I find time.

Little update: I'm currently working on extracting the chroma.js parts. Very little of it is actually needed, but chroma.js is not tree shakable unfortunately.

I've found a much better solution: don't use JavaScript at all to calculate the color scales but use a fancy new CSS feature: color-mix.
This way chroma.js could be removed completely which saves around 16 kB (gzipped) which is a reduction by around 43% :)
<EMAIL_ADDRESS>


While doing server side rendering avatars-jdenticon-sprites causing issues

While doing renderToString on server side it is giving the following error
ReferenceError: btoa is not defined
at Avatars.base64EncodeUnicode (/node_modules/@dicebear/avatars/lib/index.js:168:9)
at Avatars.create (/node_modules/@dicebear/avatars/lib/index.js:158:80)

renderToString is not a function of avatars. You are probably trying to create a base64 string, right?
I can recommend the following workaround.
https://stackoverflow.com/a/38446960

It worked!

Ich denke, auf Dauer sollten wir das Problem direkt in der Library angehen.

base64 is now deprecated. Use dataUri instead.


Prompt Error, TimeOut error

2024-11-20 16:06:08,086 - ERROR - Prompt fix_output_format failed to parse output: The output parser failed to parse the output including retries.
2024-11-20 16:06:08,093 - ERROR - Prompt fix_output_format failed to parse output: The output parser failed to parse the output including retries.
2024-11-20 16:06:08,094 - ERROR - Prompt fix_output_format failed to parse output: The output parser failed to parse the output including retries.
2024-11-20 16:06:08,094 - ERROR - Prompt context_recall_classific[ ] I have checked the documentation and related resources and couldn't resolve my bug.
Describe the bug
This two errors are continuously appearing when evaluating on HuggingFace models and HF Datasets
Ragas version:latest
Python version:3.12
Code to Reproduce
Error trace
Expected behaviour:
I expect no output parser errors!!
Additional context
Add any other context about the problem here.

Hello guys ; any update on this issue? I ma still facing it blocking my pipeline..:)

Hi @giambascientist86, I encountered the same issue and managed to resolve it by using a callback to capture the format of the prompt and the model's output. I actually came across a great solution in #1729, which worked really well.
Here's how I did it:
from langchain_core.callbacks import BaseCallbackHandler
from ragas import evaluate,RunConfig

class TestCallback(BaseCallbackHandler):

    def on_llm_start(self, serialized, prompts, **kwargs):
        print(f"**********Prompts*********:\n {prompts[0]}\n\n")

    def on_llm_end(self, response, **kwargs):
        print(f"**********Response**********:\n {response}\n\n")

score = evaluate(dataset,metrics=[faithfulness],
                 llm=llm,
                 embeddings=azure_embeddings,
                 raise_exceptions=True,
                 callbacks=[TestCallback()],
                 run_config=RunConfig(timeout=10,max_retries=1,max_wait=60,max_workers=1)
                )
score.to_pandas()

Hope it helps!
Also I use ragas == 0.2.6


Updated message diagrams.

Proposed changes
Updated communication flows.
Fixes
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[ ] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[ ] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have locally run services that could be impacted and they do not present failures derived from my changes

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

Why do you not want it to be merged?

Why do you not want it to be merged?

Sorry, forgot to remove from the title. It can be merged.


Update Razor binary dependencies

These updates should fix the release blockers identified by @NTaylorMullen.

@SteveSandersonMS @NTaylorMullen The build is failing with
npm ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
npm ERR!
npm ERR!
npm ERR! Invalid: lock file's microsoft.aspnetcore.razor.vscode@https://download.visualstudio.microsoft.com/download/pr/273c49f3-fc9b-4140-bc65-b47b9ac61267/84c3319bc81e794e873cb931084cb6c8/microsoft.aspnetcore.razor.vscode-1.0.0-alpha1-20181003.5.tgz does not satisfy microsoft.aspnetcore.razor.vscode@https://download.visualstudio.microsoft.com/download/pr/eee89386-9a82-4b4c-b30a-5857138f2eff/b0583648506c8fffe1ed9ff202702387/microsoft.aspnetcore.razor.vscode-1.0.0-alpha1-20181006.7.tg

@SteveSandersonMS would know better than I as to why. I'm an npm noob 😉

@SteveSandersonMS ping

Rebased on master and regenerated package-lock.json. Hopefully CI will be OK now!


Create CI template for kustumized deploy/destroy

Fixes #43

nit: Kustomize is misspelled in PR title

Please create documentation for the new actions and then new workflow similar to the already existing documentation


Is it possible to apply CLIP-ReID to visible-infrared person re-identification?

Hello, I appreciate your kind words about the excellent results and research sharing.
I would like to know if it is possible to combine Clip with visible-infrared person re-identification to improve the performance of the model.

@wanderer1230 I can't see any reason why it wouldn't work. Did you ever try it? I'm curious to hear your results.
Also, have you looked at this paper? It may be of interest to you: https://arxiv.org/html/2401.05806v2


Draft: Automatically Build Image Using GitHub Actions

The new GitHub Action does two things:

Builds all three images.
Uploads to DockerHub with an image tag corresponding to the state of the repository.

The advantages are automated testing and deployment of the official images used by Muon Collider Collaboration. The testing goes beyond just making sure the images build. The automatically deployed work-in-progress images from Pull Requests can be pulled by users to test specific Processors. Long term, we can also add Actions that automatically test commonly used Processors.
This PR implements the standard docker/build-push-action@v2 workflow. Some important highlight are next.
Docker Image Tag
The images are tagged as "${DOCKERHUB_REPOSITORY}/imagename:${steps.meta.outputs.version}-centos8", where the meta step is an execution of docker/metadata-action@v3. The version is either pr-# (where # is the number of the PR), tag (for tagged ref's) or master (for direct pushes to master).
One caveat is that the tag is taken directly. So the current tag format would result in an image named infnpd/mucoll-ilc-framework:v.1.5-centos8.  There is support for semver formatted tags which strip the v from vX.Y.Z. Our tag format is quite close to this, so it might be possible to use.
Dockerfile Changes
The automatic repository / version information needs to be forwarded to the later stage Dockerfiles (Dockerfile-ilc-base and Dockerfile-ilc-framework). This PR replaces the hard-coded information with the following Docker arguments.

Argument
Default

REPOSITORY
infnpd

VERSION
devel

The README instructions have been updated correspondingly.
Repository Secrets
The action expects the following variables to be defined as secrets.

Secret
Description

DOCKERHUB_USERNAME
Username to use during the push action.

DOCKERHUB_TOKEN
API token associated with the username.

DOCKERHUB_REPOSITORY
Repository where to save the image.

TODO

Fix transformation from tag to the current image tag format.

Hi @pandreetto,
I'm almost done with this. Just need to

fix the git tag to image version formatting
address any comments from you

I'm not sure why the Action isn't running in this PR. Could you please check the "Action" tab in Settings if something is disabled? There also might be an "Approve and run" button in your view above the "Merge pull request" button for you to click as I am an outside collaborator. Note that the CI would fail anyways and the secrets first need to be setup.
In the meantime, you can see the action in action in at fork and my DockerHub repository.
--
Karol Krizka


Improve logging configuration

The current ringo/logging is based on the early Log4J implementation from Helma NG times. We should clarify the configuration and introduce some debugging features.
I would also recommend not to touch the logger names by replacing / with . in the getLogger() method, since core modules don't do that replacement neither.

I started a branch for this issue for further discussions: #445


Example use cases

[Enter feedback here]
As-Is: For example, developers might have contributor access in production subscriptions but only reader access in nonproduction subscriptions.
To-be: For example, developers might have contributor access in nonproduction subscriptions but only reader access in production subscriptions.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4b24efd3-3fda-7c73-6bf6-cfed8a3e2785
Version Independent ID: 95e455f3-674a-7554-bfd8-d43e46c60271
Content: Organize and manage multiple Azure subscriptions - Cloud Adoption Framework
Content Source: docs/ready/azure-best-practices/organize-subscriptions.md
Service: cloud-adoption-framework
Sub-service: ready
GitHub Login: @alexbuckgit
Microsoft Alias: abuck

Thanks for reporting - this issue is under review.  This is a Microsoft Internal DevOps Bug ID AB#336738

This issue has been resolved. Thanks for the feedback!


Feature request: content type for agent messages

Is your feature request related to a problem?
Other clients have no way of knowing whether a message was sent by a human or an agent.
Describe the solution to the problem
Use TextEncoder() with a new agent-message ContentTypeId for all generated messages. This is not a trustless solution.
e.g.
import {
  ContentTypeId,
  ContentCodec,
  EncodedContent,
} from "@xmtp/content-type-primitives";

export const ContentTypeAgentMessage = new ContentTypeId({
  authorityId: "xmtp.org",
  typeId: "agent-message",
  versionMajor: 1,
  versionMinor: 0,
});

export class AgentMessageCodec implements ContentCodec<string> {
  contentType = ContentTypeAgentMessage;

  encode(content: string): EncodedContent {
    return {
      type: this.contentType,
      parameters: {},
      content: new TextEncoder().encode(content),
      fallback: content,
    };
  }

  decode(encodedContent: EncodedContent): string {
    return new TextDecoder().decode(encodedContent.content);
  }

  fallback(content: string): string | undefined {
    return content;
  }

  shouldPush(): boolean {
    return true;
  }
}

Describe the uses cases for the feature
A client like Converse may wish to display messages differently if they are known to be agents.
An agent may want to handle agent-generated messages differently from messages assumed to be from humans. For instance, an agent may wish to ignore other agents to prevent loops.
Additional details
No response

Agent Message Content Type
The AgentMessage content type allows XMTP agents to send messages with hidden metadata while maintaining compatibility with regular clients.
Structure
class AgentMessage {
  text: string;      // Visible message content
  metadata: {
    agentId: string;
    skillUsed?: string;
    timestamp: number;
    isAutomated: boolean;
    [key: string]: any; // Additional custom metadata
  }
}

Usage
Basic Message
await context.sendAgentMessage("Hello!", {
  agentId: "support-bot"
});

Message with Skill Info
await context.sendAgentMessage("The domain is available!", {
  agentId: "ens-bot",
  skillUsed: "check-domain",
  domainChecked: "fabri.eth"
});

Tested in Coinbase Wallet and Converse
Message Can be Empty


Cant share a website in android (Octet Stream format)

im running into a very strange issue when sharing a website in android (only).  when i share a website,  i am getting a type "application/octet-stream", with the uri showing that it is a "BlockedFile".

Is this a permissions issue?  Why cant I share a website in android, and what is this weird octet-stream file?

I am not sure how this plugin is supposed to handle a website etc. I am only using it for images.

same here , any update ? thanks


Update tabletest.md

OPS Build status updates of commit 1b26ad9:
:clock10: Preparing: average preparing time is 40 sec(s)

OPS Build status updates of commit 1b26ad9:
:clock10: Incremental building: average incremental building time is 8 sec(s)

OPS Build status updates of commit 1b26ad9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

APEXTest/CATSTesting/Playground/tabletest.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Title: login signup page with Google

Initiative (Required)
GSSoC (Girl Script Summer of Code) 🌸
Is your feature request related to a problem? Please describe.
We can implement a sign in page with Google
Describe the solution you'd like.
I am willing to work on this please assign me
Add any other context or screenshots about the feature request here.
No response

I am the mentor of this project.
Hello @Sawan-Kushwah
I appreciate your pull issue, can you give screenshots!!!!

https://github.com/user-attachments/assets/c5df3d6f-4a4e-46f7-8596-47c81c156554
@SakiraAli1115
it will work something like this i have implemented this
you can sign in with google or custom mail feature !

@Kushal997-das kindly assign this issue!!
@Sawan-Kushwah tell me where you can contribute?

Firebase or oauth 2.0 I can do both ?

@SakiraAli1115 Please assign me this so that i can start working on this , if its suits you !?

@Kushal997-das Can i wok on it ? requested to assign me this issue..

@Kushal997-das  i will make pr today


automatice Audit ?

Sorry about this question, I used the "remediate ansible" version and it's really great.
Now I would like to be able to run tests against the servers, as I read the remediation Ansible is not recommended for testing, here I am reading about Goss.
How does this work ? Can I run it from ansible ? Or do I have to run from each server
Sorry about this simple question but "goss" is very new for me.

hi @txsastre
The audit can run in an automated way from remediate, i you look at the defaults/main.yml you will see a few settings you may want to change.
setup_audit
run_audit
There is more information in the readthedocs
there has been a few questions around this so watch the community as we may post a video to provide further information.
Hope that helps
uk-bolly

hi there
thank you very much I've changed in /defaults/main.yml
##########################################
Refer to vars/auditd.yml for any other settings
Allow audit to setup the requirements including installing git (if option chosen and downloading and adding goss binary to system)
setup_audit: true
enable audits to run - this runs the audit and get the latest content
run_audit: true
Only run Audit do not remediate
audit_only: true
As part of audit_only
This will enable files to be copied back to control node
fetch_audit_files: true
but it also has modified the clients (hardened)
also checked community in https://discord.io/ansible-lockdown but it does not load
a video of how to configure all together would be really great.
by the way thank you very much for you playbooks and work

yes it it.
we solved the problems via Discord.
This can be close.
Thanks

yes it it.
we solved the problems via Discord.
This can be close.
Thanks


CoreLibs does not indicate blocked HTTPS tunnel requests

Steps to reproduce:

Add ||example.org to the user filter
Disable HTTPS filtering for the Chrome browser in the Apps Management settings
Try opening example.org in Chrome

Expected result:
onRequestProcessed is called for the example.org tunnel (with the blocking rule info)
Actual result:
onRequestProcessed is not called at all

May be related to #248

Merged, core/pull-requests/284

Filter result was not assigned in onRequestProcessed event, which caused event not being logged.
Fixed in core/pull-requests/292


--validate throws an npm error if translation is invalid

 i18n-tag-schema ./translations --validate --schema ./translation.schema.json throws an npm error if translation is invalid

@sebudde This is an expected behavior of npm if a cli process exits with an error code.

ok. but in that case the script should not exit with an error 'cause having unknown or missing keys is not an "error" in my general understanding of errors.

It is a validation error because it checks for required keys and fails if those keys are missing. The cli returns an error code in this case to stop execution of following commands.
If you only want to deploy your application if all translations are valid this can be very handy. If you use the cli like npm run validate-translations && npm run deploy, the deploy script will not run if the validation failes.


Redeploying with webhooks when using a unique image name

I haven't been using commit hashes in my docker image names (the image name stays the same). Therefore, it's been trivial to redeploy from a CI build to production swarm using a portainer webhook. 👍
Example: (drone.io) pipeline yaml file

However, keeping the same image name does not allow me to maintain a history of docker images in Docker Hub. This is important because I also want the ability to rollback to previous images.
I want to move towards unique image names using a commit hash, for example, (image name: devpies/appname:prod-ee134ak342cb235ms). Sounds great but it changes my workflow. 😭
With this approach, how may I trigger a redeploy from a CI pipeline? My portainer webhook strategy won’t work anymore with unique image names. Portainer would just redeploy with the older image since the service is tied to it directly.
The more I ask this question I think I'm getting closer to the solution.
Maybe I need to use the portainer api to update the image dependency of the service before triggering the webhook? Could the webhook strategy still work this way? Since the service name stays the same? I haven’t actually given this a shot.
All I know is SSHing into a server manually is a no go. I don’t want to keep track of server ips; manually connecting to a server, cleaning up and redeploying seems a bit cumbersome. Anyone have a workflow that works for them?

@ivorscott did you know that you can specify an image tag when using the service update webhook? This was introduced in 1.21.0 via https://github.com/portainer/portainer/issues/2752
Would that solve your problem?

I will try this. Thank you for a fast response!

I will try this. Thanks for the quick response!

Great, feel free to comment in here if you need help with the usage of the webhook.


Unable to run plrust from M1 mac due to version mismatch

I have followed the documentation Getting Started and while running I am getting the version mismatch issue.
dsivaji@Dineshs-MacBook-Pro plrust % cargo pgrx run pg14 --release
Error:
   0: `pgrx-0.9.7` shouldn't be used with `cargo-pgrx-0.9.8`, please use `pgrx = "~0.9.8"` in your `Cargo.toml`.

Location:
   /Users/dsivaji/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pgrx-0.9.8/src/metadata.rs:42

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

   0: cargo_pgrx::metadata::validate
      at /Users/dsivaji/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pgrx-0.9.8/src/metadata.rs:27
   1: cargo_pgrx::command::run::execute
      at /Users/dsivaji/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pgrx-0.9.8/src/command/run.rs:55

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
dsivaji@Dineshs-MacBook-Pro plrust %

Changing the version to 0.9.8 led to another issue
dsivaji@Dineshs-MacBook-Pro plrust % cargo pgrx run pg14 --release
Error:
   0: couldn't get cargo metadata
   1: `cargo metadata` exited with an error:     Updating crates.io index
      error: failed to select a version for `pgrx`.
          ... required by package `plrust-trusted-pgrx v1.2.3 (/Users/dsivaji/Projects/rust-learnings/plrust_work/plrust/plrust-trusted-pgrx)`
      versions that meet the requirements `=0.9.7` are: 0.9.7

      all possible versions conflict with previously selected packages.

        previously selected package `pgrx v0.9.8`
          ... which satisfies dependency `pgrx = "=0.9.8"` of package `plrust v1.2.3 (/Users/dsivaji/Projects/rust-learnings/plrust_work/plrust/plrust)`

      failed to select a version for `pgrx` which could resolve this conflict

Location:
   /Users/dsivaji/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pgrx-0.9.8/src/metadata.rs:23

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

   0: cargo_pgrx::command::run::execute
      at /Users/dsivaji/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-pgrx-0.9.8/src/command/run.rs:55

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

It Worked, Thanks!


[BUG]: PowerScale volumes unable to be created with Helm deployment of CSM Authorization

Bug Description
CSI PowerScale gets request denied error from CSM Authoriztion when creating a volume.
Logs
 {{ time="2022-08-02T14:32:18Z" level=error clusterName=pieisi93x runid=17 msg="create volume failed, 'request denied: '" file="/go/src/service/isiService.go:105"}}
{{ time="2022-08-02T14:32:18Z" level=info msg="/csi.v1.Controller/CreateVolume: REP 0017: request denied: "}}

Screenshots
No response
Additional Environment Information
No response
Steps to Reproduce
Deploy CSI PowerScale with CSM Authorization.
Deploy a PVC with powerscale storage class.
Expected Behavior
Volume should be created.
CSM Driver(s)
CSI Driver for PowerScale
Installation Type
No response
Container Storage Modules Enabled
No response
Container Orchestrator
Kubernetes 1.24
Operating System
RHEL 8.4

Thanks your fixing so quickly


(doc) Fix formatting in "Where can I get psake"

Description
This PR modifies doc. It adds a new line after paragraph to help MKDocs understand the following lines form a list.
Motivation and Context
It fixes a formatting issue on the page https://psake.readthedocs.io/en/latest/where-can-i-get-psake/. Without newline, MKDocs doesn't understand Markdown.
Screenshots (if appropriate):
Before my changes:

After:

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

@alexandear Thanks!


Allow build on PHP 7

When I'm trying to build with travis on PHP 7:

phalcon/zephir dev-master requires php ~5.3 -> your PHP version does not satisfy that requirement.

Why would you try to use zephir with PHP7?
It just does not compile, so why would you want to run tests?
Or do you just use the zephir compiler/composer with PHP7?
(And no upgrading zephir to PHPNG is not very trivial, see the issue on the matter)

I'm aware of this, I just wanted to see what stops the compilation.

Fundamental changes to the zend engine ^^
(They require fundamental changes (weeks of work atleast)
to zephir, I will probably release my experiment soonish,
which will provide atleast 100% working tests of zephir)
Enabling tests for something that only fails (and cannot work) does just not make sense.
That's something that should be done when implementing PHP7 support.

:+1:

:+1:

@steffengy You are welcome (help with PHP 7 support)

Thank you @mruz


[Serverless Hacks] Container App pushing custom metrics to itself

What is your Name & GitHub Profile?
Name: Simon Gottschlag
GitHub: simongottschlag
What is the GitHub Repo for your Serverless Hack solution?
https://github.com/XenitAB/azcagit/pull/25
Did you make any enhancements or extensions to the default hack?
Yes
(If Yes) Tell us a little about what you did, and why
I used Golang to get a Container App to push custom metrics to Azure.
(Optional) Anything else you want us to know about this Serverless Hack?
Recording of me figuring it out and implementing it: https://youtu.be/TnayUNLj8co

cc @devanshidiaries  @madebygps


Add support for Windows Server 1803, 1809

Changes microsoft/windowsservercore to mcr.microsoft.com/windows/servercore.
Also, adding support for Windows Server 1803 and 1809.

Thanks! :+1:


[google_maps] Randomly crashes with java.lang.NullPointerException

Flutter application suddenly crashed on the initial render of the google map, with unhandled exception:
java.lang.NullPointerException: Attempt to get length of null array at java.nio.ByteBufferAsShortBuffer.put(ByteBufferAsShortBuffer.java:121)
Steps to Reproduce
Issue is not reproducible on minimal example, not even in the same Flutter application the bug actually happened. Restarting the app fixed the issue.
What happened before and after:

App crashed on hot reload when developing (not sure if relevant)
I decided to terminate the process and performed rebuild and re-run
App immediately crashed when map loaded

Details
Re-running the application with verbose option won't help, as the application loaded fine on second re-run.
There are no relevant analysis errors. (we just have snackbar deprecation warnings from upgrading to 2.0)

Logs
E/AndroidRuntime(31038): FATAL EXCEPTION: GLThread 15083
E/AndroidRuntime(31038): Process: com.***.app.bundle.name, PID: 31038
E/AndroidRuntime(31038): java.lang.NullPointerException: Attempt to get length of null array
E/AndroidRuntime(31038): 	at java.nio.ByteBufferAsShortBuffer.put(ByteBufferAsShortBuffer.java:121)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.gl.buffer.c.m(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):2)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.gl.buffer.c.l(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):1)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.a.t(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):6)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.bg.E(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):4)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.bg.t(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):5)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.bs.c(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):144)
E/AndroidRuntime(31038): 	at com.google.maps.api.android.lib6.gmm6.vector.an.run(:com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(100406-0):49)
[MapBloc.MESSAGE] MapCreated
I/Process (31038): Sending signal. PID: 31038 SIG: 9
Lost connection to device.

I've copied complete logcat from the device roughly around the time the app started, was running and crashed. I've just redacted our bundle name, so it accidentally don't pop up in google search.
https://gist.github.com/marianhlavac/83018ac57a1de64c8d1ea3de8501be59
It's mostly unusable mess, but it might give some insight, if someone knows what he's looking for.
[✓] Flutter (Channel stable, 2.0.3, on Mac OS X 10.15.7 19H114 darwin-x64, locale en-GB)
    • Flutter version 2.0.3 at /usr/local/Caskroom/flutter/1.22.5/flutter
    • Framework revision 4d7946a68d (13 days ago), 2021-03-18 17:24:33 -0700
    • Engine revision 3459eb2436
    • Dart version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/marian/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.54.3)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.20.0

[✓] Connected device (2 available)
    • Redmi 7 (mobile) • df7268bc • android-arm64  • Android 9 (API 28)
    • Chrome (web)     • chrome   • web-javascript • Google Chrome 89.0.4389.114

• No issues found!

I understand that the given amount of information isn't sufficient to resolve the issue. But since it's not reproducible, it's all I have for now.
I'm willing to provide more information on how we use Google map in our app, or to perform some tests on the Android device, if it becomes a suspect. Should I collect any specific information, next time the issue occurs again?
Thanks.

@marianhlavac
Thanks for the report. On your first point, App crashed on hot reload when developing (not sure if relevant), what kind of crash did it throw ? Was it the same crash or different ? Is there a way to trigger this crash again and provide it ?
App immediately crashed when map loaded. Can you please elaborate on the scenario in which you are loading the map ? Does it load after triggering some other action or as soon as the app is launched ? If possible, can you provide a use case around it which may possibly trigger the crash ?
I also think that since the crash is coming from native java.lang.NullPointerException: Attempt to get length of null array at java.nio.ByteBufferAsShortBuffer.put(ByteBufferAsShortBuffer.java:121) and doesn't point to any file related to the plugin, it could be an issue from Android side.  See this similar issue for your reference, https://stackoverflow.com/questions/27253524/attempt-to-get-length-of-null-array-in-google-maps-v2-android-app

@darshankawar Thanks for the quick reply.

what kind of crash did it throw?

The crash is a segmentation fault that happens to me from time to time when hot reloading.
F/libc    (18572): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x340117 in tid 18656 (1.ui), pid 18572 (****)

I also think that since the crash is coming from native and doesn't point to any file related to the plugin

I agree, I stumbled upon the same link on stack overflow you've sent, but never noticed the other link mentioned in one of the answers leading to this issue:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=5100#c34
It seems like the exact issue I've encountered and other people describe it the same - it happens only sometimes.
It really looks like native issue. I will continue the discussion in the google issue tracker thread, and for the crashing hot reload I will collect more data, look for other existing issues or open a new issue dedicated to the hot reload problems.
Thanks for the assistance.


Add support to spawn the process

Hey there,
How hard would it be to allow the child process to be spawned instead of executed on this module? I didn't take a look myself, but I suspect it's just a matter of spawning the final command built by this module in Attempt().
The use case is that we've figured out how to call the process that needs the elevation in Etcher, instead of the full application, but we need to consume its stdout and stderr while it runs in order to get state information.
In my mind, the sudoPrompt.spawn() function should just return the spawn object for the client to handle.
What do you think about this addition? Happy to collaborate on it.

It is possible but would be a fair amount of work. Would be great if you could tackle it.
The Attempt() call is just the tip of the iceberg. That's there to try and run the command if a sudo session already exists, and if it does then that could be just a straight-forward spawn() instance passed back to the user.
But otherwise, the user command is run by a bash subshell which is called by the applet after acquiring administrator privileges. So we would essentially be trying to create a fake spawn() instance with all the same properties as a normal Node.js spawn() instance, but which wraps a bash subshell.
To understand how this works:

Add a console.log() statement to print out instance.path just after MacCommand() runs (https://github.com/jorangreef/sudo-prompt/blob/master/index.js#L196). This is the path to the temporary app created by sudo-prompt.

Before granting privileges, take a look at the logged path and then open it in Finder and make a copy of the temp app. The app will otherwise be deleted as soon as privileges are granted.

Open the app with Script Editor to view the Apple Script source, and then take a look in the MacOS directory within the app to see the bash scripts which are there.

If we can do this properly that would be great, but some aspects of the spawn() instance might be difficult to copy perfectly. Alternatively, it might be easier to write out your script's stdout and stderr streams to a file and tail those.

Hi @jorangreef
I see :/ I certainly underestimated the amount of work needed. I'll take the tail approach as you suggested and see how far I can get with it.
I'll re-open this issue if needed, thanks a lot!


Improve archiving from etherpad URL

From chat today with @capjamesg and @tantek:
It would be nice if we could use only an etherpad URL with the command:
!archive https://etherpad.indieweb.org/YYYY-MM-DD-hwc-shortname
Suggested parsing:

Parse the ISO8601 YYYY-MM-DD format date from the etherpad slug, set that as the date

If none found, set date as "ADD DATE"

Find the common HWC shortname in the etherpad slug and set the full event_name:

hwc-europe = "Homebrew Website Club Europe/London"
hwc-pacific = "Homebrew Website Club - Pacific"
If no common short name found, default to "Homebrew Website Club"

Find the first events.indieweb.org link in the etherpad contents, set that as the permalink

If none found, set permalink as https://events.indieweb.org

Then the final wiki page contents would be:
<dfn>[`permalink` `event_name`]</dfn> was an IndieWeb meetup on Zoom held on `date`.

Archived from: `etherpad_url`

`etherpad contents`

HWC Organizers would need to ensure:

their etherpad slugs use the format listed above
the events.indieweb.org permalink is added somewhere in the etherpad

Thoughts?

For reference, this was discussed a lot here: https://chat.indieweb.org/meta/2023-03-30#bottom

I've made some good progress on this. Hoping to have a PR ready this weekend.

Amazing! Thank you!


Support for LoRA adapters?

I was just wondering if there was support for loading LLaMA models with LoRA weights applied like llama.cpp has. I couldn't find any existing discussions about this. This project would be perfect for my use case but only if this is possible.

Not at the moment, but we'd love to support it at some point.

Is case someone wants to contribute, what would be involved in implementing this?

It's somewhat involved - you would have to replicate this function https://github.com/ggerganov/llama.cpp/blob/master/llama.cpp#L2151, which loads both the LoRA and the original model, and then patches the tensors with the LoRA data.
Our abstractions are different (especially in how we handle model loading), so it's not going to be the most straightforward thing. That being said, if you or anyone else is interested, I'd encourage you to swing by our Discord to chat to us about how to do it.

@NatanFreeman Could you provide a LoRA adapter and a matching base model in ggml format? Or could you point us to somewhere where we can find one?

For the base model I just converted the LLaMA weights using convert-pth-to-ggml.py. I cannot provide the LoRA adapter I am using because it was trained on private data. Instead, you can use these LoRA weights and convert them using convert-lora-to-ggml.py to get weights in the same format.

Sorry if there is a well known answer, but why would you fuse the Lora layers into the rest of the model? The fact that a single model can have different variants just by swapping out the (relatively) tiny Lora layers is a feature, no?

@daniel-vainsencher LoRA is applied by patching the weights of existing layers in a model via patched_tensor = original_tensor + BA *s. The B and A Tensors are provided by the lora adapter. The base model is patched in-memory meaning if you want to apply a different LoRA adapter you simply have to reload the model with a different adapter.

Got it, thanks for explaining the what, but I asked about the why.
Instead you can use at inference time
Patched * x as Original*x + A(Bx)
which is cheap because A, B are each small. This exactly allows us to avoid swapping out the large O(riginal) weights, and instead be able to infere on multiple Lora variants of the same model by just swapping out their A, B.

@daniel-vainsencher Oh alright, atm we don't have good abstractions on the inference side for the implemented architectures. If we wanted to apply the LoRA weights during inference we would need to update the inference code for every existing and upcoming architecture. I wanted to keep compatability with the existing codebase and decided to apply the patches during loading. This way we don't have to change any inference code and its simpler to port over existing implementations from e.g. llama.cpp.
Maybe in the future when we have better abstractions layers we could move the LoRA adapter back into the inference function.
But that's also debatable as we want to execute only needed calculations, even if they are relatively simple. By applying the weights during loading we only have to calculate them once and not every inference call 🤔

Done in #211

@NatanFreeman well i can point you towards this https://github.com/rustformers/llm/pull/211#issue-1705736482 . But its basically the normal inference code and you just have to add an optional parameter to the ModelParameters while loading the model. If you have any problems let me know.

It works. Is there away of using multiple LoRAs on top of each other?

Uhm not right now, i dont even know how that would work. Are they patching the same Tensors or different ones? And If they are patching the same tensors the order in which the adapters are applied would be important.
Could you please explain how the patching process works with multiple files?

I'm not sure how the implementation is done but this Python code cell works:
from peft import PeftModel
from transformers import LLaMATokenizer, LLaMAForCausalLM, GenerationConfig

tokenizer = LLaMATokenizer.from_pretrained("decapoda-research/llama-7b-hf")

model = LLaMAForCausalLM.from_pretrained(
    "decapoda-research/llama-7b-hf",
    load_in_8bit=True,
    device_map="auto",
)
model = PeftModel.from_pretrained(model, "Naataan/Model-A")
model = PeftModel.from_pretrained(model, "Naataan/Model-B")

# save the applied weights to a new bin file
PROMPT = """Below is an instruction that describes a task. Write a response that appropriately completes the request.
### Instruction:
Natan: Hello.
Name the 3 biggest cities in England
### Response:"""

inputs = tokenizer(
    PROMPT,
    return_tensors="pt",
)
input_ids = inputs["input_ids"].cuda()

generation_config = GenerationConfig(
    temperature=0.6,
    top_p=0.95,
    repetition_penalty=1.15,
)
print("Generating...")
generation_output = model.generate(
    input_ids=input_ids,
    generation_config=generation_config,
    return_dict_in_generate=True,
    output_scores=True,
    max_new_tokens=128,
)
for s in generation_output.sequences:
    print(tokenizer.decode(s))

Perhaps the peft documentation has the answer.

Alright i probably have to read some peft source code and check what they are doing. I'm gonna create a new issue for this.
Oh and i would greatly appreciate it if you could provide/link to any LoRA adapter that's split into multiple parts :D


Channel Logo Request

if anyone has any request i can try to whip something up
i will add to list so i have something to work off of.
request in this form plz

channel name
Movie Or TV Show
kind of logo (text and/or icon)
include slogan (yes, no)
slogan (text to put)

Creature Double Feature
Movie
Icon and text
no
none

FlashBack TV
Tv Show
text and icon
no
none

Flip Television
Tv Show
text
no
nano

Hero TV
Movie
icon and test
yes
Movies 4 Heros

Retro TV
Tv Show
icon and test
no
none

Slappy
Tv Show
icon and test
no
none

Sorry about the apathy, the issues forum is not very active.
We are going to open a repository for (not trademarked) channel assets soon, hope to see you around when that happens.


Make the return type of query methods non-nullable when using the "strict" option

const user = db.user.findFirst({
  where: { ... },
  strict: true
})

The value of user cannot be null. It's either a value or an exception is thrown.

Funny enough, the conditional return type of a function is impossible in TypeScript. You can annotate it to behave properly using extend, but you can never implement such a function (you'd have to resort to any). TypeScript doesn't correlate your conditional types and the runtime value types in the function.


Agent fails to load configuration from opaque classpath resource

The io.resource framework introduced in jmxtrans-agent 1.2.3 causes a load-time failure if the classpath URI is not hierarchical. For example:
java -javaagent:org.jmxtrans.agent.jmxtrans-agent-1.2.3.jar=classpath:jmxtrans-config.xml ...

SEVERE [main] org.jmxtrans.agent.JmxTransAgent - Exception loading JmxTransExporter from 'classpath:jmxtrans-config.xml'
java.lang.IllegalArgumentException: URI is not hierarchical
	at java.io.File.<init>(File.java:418)
	at org.jmxtrans.agent.util.io.ClasspathResource.getFile(ClasspathResource.java:68)
	at org.jmxtrans.agent.util.io.IoUtils.getFileAsDocument(IoUtils.java:153)
	at org.jmxtrans.agent.JmxTransConfigurationXmlLoader.loadConfiguration(JmxTransConfigurationXmlLoader.java:80)
	at org.jmxtrans.agent.JmxTransExporter.loadNewConfiguration(JmxTransExporter.java:74)
	at org.jmxtrans.agent.JmxTransExporter.<init>(JmxTransExporter.java:70)
	at org.jmxtrans.agent.JmxTransAgent.initializeAgent(JmxTransAgent.java:99)
	at org.jmxtrans.agent.JmxTransAgent.premain(JmxTransAgent.java:84)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
	at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:401)

Thanks for the detailed report @tcrossland . I'm investigating.

@tcrossland can you please give us one more details please: is jmxtrans-config.xml contained in a jar or is on the file system?

It's in one of the jars on the classpath (i.e. it's copied from src/main/resources by maven, or in this case, SBT). The same (opaque) classpath URI works with 1.2.2 of jmxtrans-agent.

Thanks @tcrossland. I have just verified that the problem does not happen with a config file on the file system :-)
I suspect that you can workaround prefixing the filename with /.
Can you try to reproduce with https://oss.sonatype.org/content/repositories/snapshots/org/jmxtrans/agent/jmxtrans-agent/1.2.4-SNAPSHOT/jmxtrans-agent-1.2.4-20160525.221853-2.jar
You should have a better exception message. I'm based in France and it's late, I'll continue to investigate tomorrow.
Cyrille

I tried using a leading / (classpath:///jmxtrans-config.xml and classpath:/jmxtrans-config.xml) but both failed with an NPE (I've lost the stacktrace from my terminal scrollback, also a bit late here in Spain!). In any case, no hurry, 1.2.2 is working fine.

@cyrille-leclerc I suspect the problem is at org.jmxtrans.agent.util.io.ClasspathResource.getFile() - AFAIK, it is not possible to create File objects for files that reside within a jar file. We probably will have to work with only the stream when reading configuration from within a jar.

@kerlandsson good catch! I'm fixing

@tcrossland I am working on a fix on my fork https://github.com/cyrille-leclerc/jmxtrans-agent/commit/8d853c872cddfd04d6928f5143df4d61f5ceb23a
I did not have the time to finish my tests but this should do the job. Would you have the time to verify?
https://oss.sonatype.org/content/repositories/snapshots/org/jmxtrans/agent/jmxtrans-agent/1.2.4-SNAPSHOT/jmxtrans-agent-1.2.4-20160526.092044-4.jar

I'll try tomorrow and let you know. Thanks for the quick fix!

Sorry, haven't found time to test it yet... will get round to it soon.

Hi, finally got round to testing the snapshot version, works correctly loading classpath resources. Many thanks!


Installation of getfamed.

System Information
Tried to install the getfamed.
Detailed description
Installation steps are clear and tried the same.
Steps to reproduce
Open the URL.
Install using the steps guide.
Issue submission checklist

[X] I report the issue, it's not a question
[X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
[X] I updated to the latest OpenCV version and the issue is still there
[X] There is reproducer code and related data files (videos, images, onnx, etc)

Closing it.


WIP: update changelog for v2.1.0

Signed-off-by: Thomas Labarussias<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area tests

What this PR does / why we need it:
PR for v2.1.0
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 2a41357c2a6ef397327de1825e9c6713d2bc68c2

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fjogeleit, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif,fjogeleit]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Changed 'Show the Local Weather' wording to fix #2623

Please remove the issue number from the title and add it the body of the commit.
see: https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/Pull-Request-Contribute

This indeed makes more sense.


Some Feeds are not loading or loading with issues

Hello,
I use Yahoo Pipes to convert feeds with only description to full text feeds.
when i imported my Google reader subscriptions all of these feeds didn't work and are marked with read.
1.so for example this link doesn't display the full text feed, on the other hand when used in Google Reader, AOL Reader, Feedly and many other rss readers it works properly:
http://pipes.yahoo.com/pipes/pipe.run?_id=c996480e211b600770ff2d1853d61a0c&_render=rss
2.this link almost the same as the above with "&renderer=mobile" at the end, works great on all other rss reader but on commafeed it says: "Error while loading... Unable to refresh... Read timed out":
http://pipes.yahoo.com/pipes/pipe.run?_id=c996480e211b600770ff2d1853d61a0c&_render=rss&renderer=mobile
3.i used many other sites to convert to full rss feeds and most of them had the same problem or didnt load more than 3 items when on other readers they load more.
try copy and past the links in firefox url and they will display 30 full text rss feed items.

Not yet, but I will.。

Some websites provide feed files that do not contain the full text. I believe we can achieve full-text retrieval by incorporating a built-in Full-Text RSS service. Other RSS readers have already implemented this feature, such as Huntly and Yarr. I think our project could also consider adding this functionality.


Table padding left

Hi there, first off thanks for the amazing project, i'm really loving it rn ❤
There is a small issue with tables inside of other tables.
The table inside the expendable inherits the padding left from the expandable.

I'd recommend overriding the properties with custom CSS.

I'd recommend overriding the properties with custom CSS.

Yes, that's what I've done for now.
.wrapper :global(th) {
	padding: 0 !important;
}

.wrapper :global(td) {
	padding-left: var(--cds-spacing-05, 1rem) !important;
}

Just wanted to report it in case this is treated as a bug :)
Feel free to close if you think this is an edge case

Yes, that's what I've done for now.
.wrapper :global(th) {
	padding: 0 !important;
}

.wrapper :global(td) {
	padding-left: var(--cds-spacing-05, 1rem) !important;
}

Just wanted to report it in case this is treated as a bug :)
Feel free to close if you think this is an edge case


darktable: 3.0.2 -> 3.2.1

Motivation for this change
Release information: https://www.darktable.org/2020/08/darktable-3-2/
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@danieldk yes, after launching darktable and allowing it to upgrade the database, I had my collections still there.

@danieldk yes, after launching darktable and allowing it to upgrade the database, I had my collections still there.

Ack, probably something odd in my setup.