text:
TSan failure in TaskWaitTest.IssueTimeout

I'm seeing what I think is a flaky TSan failure in TaskWaitTest.IssueTimeout. This is in testing a new runner configuration, so I suppose it's possible that this is somehow caused by being run on a tmpfs, but that doesn't seem likely
2022-09-08T17:52:44.5302912Z [ RUN      ] TaskWaitTest.IssueTimeout
2022-09-08T17:52:44.5303215Z ThreadSanitizer:DEADLYSIGNAL
2022-09-08T17:52:44.5303642Z ==150956==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000002e99b2 bp 0x00008000021f sp 0x7ffe13c500c0 T150956)
2022-09-08T17:52:44.5304049Z ==150956==The signal is caused by a WRITE memory access.
2022-09-08T17:52:44.5304382Z ==150956==Hint: address points to the zero page.
2022-09-08T17:52:44.5322270Z     #0 __tsan::MetaMap::GetAndLock(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool) <null> (task_tests+0x2e99b1)
2022-09-08T17:52:44.5322760Z     #1 __tsan_atomic32_fetch_sub <null> (task_tests+0x2c84bd)
2022-09-08T17:52:44.5323161Z     #2 iree_task_executor_release /work/runtime/src/iree/task/executor.c:224:19 (task_tests+0x322994)
2022-09-08T17:52:44.5323653Z     #3 TaskTest::TearDown() /work/runtime/src/iree/task/testing/task_test.h:40:5 (task_tests+0x310e68)
2022-09-08T17:52:44.5324355Z     #4 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /work/third_party/googletest/googletest/src/gtest.cc:2607:10 (task_tests+0x37a48c)
2022-09-08T17:52:44.5325356Z     #5 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /work/third_party/googletest/googletest/src/gtest.cc:2643:14 (task_tests+0x37a48c)
2022-09-08T17:52:44.5326024Z     #6 testing::Test::Run() /work/third_party/googletest/googletest/src/gtest.cc:2690:3 (task_tests+0x3404ca)
2022-09-08T17:52:44.5326502Z     #7 testing::TestInfo::Run() /work/third_party/googletest/googletest/src/gtest.cc:2861:11 (task_tests+0x34202a)
2022-09-08T17:52:44.5327011Z     #8 testing::TestSuite::Run() /work/third_party/googletest/googletest/src/gtest.cc:3015:28 (task_tests+0x342f16)
2022-09-08T17:52:44.5327556Z     #9 testing::internal::UnitTestImpl::RunAllTests() /work/third_party/googletest/googletest/src/gtest.cc:5855:44 (task_tests+0x35b84b)
2022-09-08T17:52:44.5328362Z     #10 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /work/third_party/googletest/googletest/src/gtest.cc:2607:10 (task_tests+0x37b4bc)
2022-09-08T17:52:44.5329362Z     #11 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /work/third_party/googletest/googletest/src/gtest.cc:2643:14 (task_tests+0x37b4bc)
2022-09-08T17:52:44.5330098Z     #12 testing::UnitTest::Run() /work/third_party/googletest/googletest/src/gtest.cc:5438:10 (task_tests+0x35aee0)
2022-09-08T17:52:44.5330576Z     #13 RUN_ALL_TESTS() /work/third_party/googletest/googletest/include/gtest/gtest.h:2490:46 (task_tests+0x329fdb)
2022-09-08T17:52:44.5331107Z     #14 main /work/runtime/src/iree/testing/gtest_main.cc:17:10 (task_tests+0x329fdb)
2022-09-08T17:52:44.5331482Z     #15 __libc_start_main <null> (libc.so.6+0x21c86)
2022-09-08T17:52:44.5331861Z     #16 _start <null> (task_tests+0x274029)
2022-09-08T17:52:44.5332025Z
2022-09-08T17:52:44.5332191Z ThreadSanitizer can not provide additional info.
2022-09-08T17:52:44.5333177Z SUMMARY: ThreadSanitizer: SEGV (/work/build-tsan/runtime/src/iree/task/task_tests+0x2e99b1) in __tsan::MetaMap::GetAndLock(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool)
2022-09-08T17:52:44.5333650Z ==150956==ABORTING

From https://github.com/iree-org/iree/runs/8254955976

Interesting! Note, even though it happens to be reported by TSan, it's a plain null-deref crash (SEGV on unknown address 0x000000000000) not (a priori) a threading-related issue --- in other words, for all we know at this point, this looks like a general crash that might as well have occured in any non-TSan config.

Stack frame 2 is: https://github.com/iree-org/iree/blob/90bed7e145d7edf8496ba79745989a76ffe0443a/runtime/src/iree/task/executor.c#L224
But stack frame 1 says that iree_atomic_ref_count_dec was given a null pointer - meaning that executor->ref_count is NULL. A look at executor_impl.h shows that ref_count is at offset 0 in executor so that's equivalent to saying that executor is NULL.
But the code at stack frame 2 is checking that executor is not NULL before proceeding:
if (executor && iree_atomic_ref_count_dec(&executor->ref_count) == 1) {

So how can this null deref happen? One can guess that some other thread wrote NULL to executor after the first part of the above if and before the second part. In normal (non-TSan), optimized code, that would never happen, because the pointer value executor would be read once from memory into a register used by both parts of that if condition, so any data race would be papered over. I guess that the way that TSan helps uncover the issue here is that it prevents optimizing away memory accesses, allowing for the two parts of that if to get inconsistent values for executor.
If that theory is correct, TSan should have reported a data race on executor instead of continuing into the null deref.  (I checked the full log, it really didn't catch the data race per se). Don't know why it didn't, but TSan is notoriously a "best effort" sanitizer. Good, anyway, that it allowed the data race to cause inconsistent accesses, allowing us to catch the bug nonetheless.

I feel like this might be the same crash I had a few days ago (and I didn't have time to report yet...)
https://github.com/iree-org/iree/runs/8106730809
[ RUN      ] TaskWaitTest.WaitAllTimeout
ThreadSanitizer:DEADLYSIGNAL
==114970==ERROR: ThreadSanitizer: SEGV on unknown address 0x60225fed0000 (pc 0x0000002d35b8 bp 0x60225fed0000 sp 0x7ffe615f60b0 T114970)
==114970==The signal is caused by a WRITE memory access.
    #0 __tsan::Mutex::ReadLock() <null> (task_tests+0x2d35b7)
    #1 __tsan::RestoreStack(int, unsigned long long, __tsan::VarSizeStackTrace*, __tsan::MutexSet*, unsigned long*) <null> (task_tests+0x2e506f)
    #2 __tsan::ReportRace(__tsan::ThreadState*) <null> (task_tests+0x2e6409)
    #3 <null> <null> (task_tests+0x2eb459)
    #4 __tsan_write8 <null> (task_tests+0x2dc373)
    #5 iree_task_list_pop_front /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/list.c:82:19 (task_tests+0x3233e7)
    #6 iree_task_list_discard /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/list.c:32:25 (task_tests+0x3233e7)
    #7 iree_task_poller_deinitialize /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/poller.c:146:3 (task_tests+0x3245d2)
    #8 iree_task_executor_destroy /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/executor.c:206:3 (task_tests+0x322814)
    #9 iree_task_executor_release /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/executor.c:225:5 (task_tests+0x3228f1)
    #10 TaskTest::TearDown() /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/task/testing/task_test.h:39:5 (task_tests+0x310e48)
    #11 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2607:10 (task_tests+0x37a1fc)
    #12 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2643:14 (task_tests+0x37a1fc)
    #13 testing::Test::Run() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2690:3 (task_tests+0x34023a)
    #14 testing::TestInfo::Run() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2861:11 (task_tests+0x341d9a)
    #15 testing::TestSuite::Run() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:3015:28 (task_tests+0x342c86)
    #16 testing::internal::UnitTestImpl::RunAllTests() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:5855:44 (task_tests+0x35b5bb)
    #17 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2607:10 (task_tests+0x37b22c)
    #18 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:2643:14 (task_tests+0x37b22c)
    #19 testing::UnitTest::Run() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/src/gtest.cc:5438:10 (task_tests+0x35ac50)
    #20 RUN_ALL_TESTS() /home/runner/actions-runner/_work/iree/iree/third_party/googletest/googletest/include/gtest/gtest.h:2490:46 (task_tests+0x32a03b)
    #21 main /home/runner/actions-runner/_work/iree/iree/runtime/src/iree/testing/gtest_main.cc:17:10 (task_tests+0x32a03b)
    #22 __libc_start_main <null> (libc.so.6+0x21c86)
    #23 _start <null> (task_tests+0x274029)

ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV (/home/runner/actions-runner/_work/iree/iree/build-tsan/runtime/src/iree/task/task_tests+0x2d35b7) in __tsan::Mutex::ReadLock()
==114970==ABORTING

Thanks @pzread , that's great additional context to have to try to make sense of that.

Note: both of your above logs show that this is only hit in the second part of the TSan tests where we rerun only iree/base and iree/task tests 32 times to catch flaky tests (#10132). So this is showing this to be catching bugs in practice -- good!

@GMNGeoffrey @pzread have you encountered this failure again since Sep 22 (merging of the above tentative fix) ?

I'd be very curious!

Just FYI, not sure if it's related, but I encountered an ASan failure in task tests #11317 last week.

I'm still curious. Is it feasible to check past actions to investigate this? I remember playing with the script you had shared and coming away from it with an impression that GitHub didn't expose the structured CI data that I needed to answer a question like "did TSan CI failure rate or noisiness change significantly at this point in the past" let alone something per stack trace filter. Do you see a way? @GMNGeoffrey  . Else, we might as well close this.

Nothing very sophisticated. You could find failed tsan jobs and look at the rate of that. YOu could also fetch the logs, and grep them for the relevant failure message. Not necessarily worth it though

authors: GMNGeoffrey bjacob pzread

repo: iree-org/iree


text:
Ensure all operations within a dispatch can be vectorized

If all operations within a dispatch are vectorized, then fusion does not have to account for bufferization creating large stack allocations as a fallback (like here https://github.com/iree-org/iree/pull/17155/files#diff-00108699e58040af178b7949b4e7a2a27e1f8c2c178307397ae5f06e7849a79fR637 ). Currently under the iree-flow-aggressive-fusion flag it is assumed that all operations are vectorized, but there are cases where this does not hold. Such operations are blacklisted in https://github.com/iree-org/iree/pull/17155/files#diff-00108699e58040af178b7949b4e7a2a27e1f8c2c178307397ae5f06e7849a79fR509 . Ideally this method should return true always.

cc @qedawkins at the time of writing the operation that is blacklisted is Conv2DNhwcHwcf with strides == 2 which I think is not vectorized. This gets fixed with implicit gemm. So assigning this to you to drop this when implicit gemm pipeline is up.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Training a Neural Network

Character Data (strings)

Nominal :  Individual discrete items, no order. For example: color, zip code, shape.
Ordinal : Individual discrete items that can be ordered. For example: grade level, job title, Starbucks(tm) coffee size (tall, vente, grande)

Numeric Data

Interval : Numeric values, no defined start. For example, temperature. You would never say "yesterday was twice as hot as today".
Ratio : Numeric values, clearly defined start. For example, speed. You would say that "The first car is going twice as fast as the second."

encode_text_dummy -
Encode text fields, such as the iris species as a single field for each class. Three classes would become "0,0,1" "0,1,0" and "1,0,0". Encode non-target predictors this way. Good for nominal.
encode_text_index - Encode text fields, such as the iris species as a single numeric field as "0" "1" and "2". Encode the target field for a classification this way. Good for nominal.
**

encode_numeric_zscore

**
Encode numeric values as a z-score. Neural networks deal well with "centered" fields, zscore is usually a good starting point for interval/ratio.
Ordinal values can be encoded as dummy or index.
**

Dealing with missing data:

**
missing_median - Fill all missing values with the median value.
Creating the final feature vector:

to_xy -

Once all fields are numeric, this function can provide the x and y matrixes that are used to fit the neural network.
Other utility functions:
hms_string - Print out an elapsed time string.
chart_regression - Display a chart to show how well a regression performs.

working on it

license: mit

license_source: bigquery


text:
overcommit vcpu for scheduling

Summary
We need to report different count of vcpu cores for allocation as we really have count of available physical cores.
Main reason is better usage of hw, when cpu cores don't have to be used on 100%.
This feature has to be optional and configurable with argument.
We can increase and decrease count of vcpu.
Basic example
Default behavior count of vcpu is the same as count of physical cores:
--resource-manager-overcommit-vcpu 1.0
Decrease count of vcpu to half count of physical cores:
--resource-manager-overcommit-vcpu 0.5
Increase count of vcpu to double count of physical cores:
--resource-manager-overcommit-vcpu 2.0
Motivation
Better using of cpus.

merged

repo: ironcore-dev/libvirt-provider


text:
Sample script uses $PSScriptRoot, doesn't work interactively

Describe the Issue
When running the sample script interactively, the use of $PSScriptRoot results in errors if your working directory isn't the expected directory.
To Reproduce

Open PowerShell Console
Paste Sample Script
Notice errors as it executes

Expected behavior
Dynamically locate the module and reference the example script accordingly.
Screenshots

Script Sample
Offending line is number 69:
$Script = New-UAScript -Name "New User Onboarding Request" -ManualTime 28000 -ScriptBlock ([scriptblock]::Create((Get-Content "$PSScriptRoot\UniversalAutomation.Dashboard\examplescripts\onboarding.ps1"))) -Status "Draft"

Suggest change to:
$Script = New-UAScript -Name "New User Onboarding Request" -ManualTime 28000 -ScriptBlock ([scriptblock]::Create((Get-Content "$((Get-Module UniversalAutomation.Dashboard -ListAvailable).ModuleBase)\examplescripts\onboarding.ps1"))) -Status "Draft"

Version Information

Host Operating System: Windows 10 1909
Host PowerShell Version: 5.1.18362.145
Universal Automation Version: 1.0.0
Universal Dashboard Version: 2.7.0
UD Hosting Method: PowerShell

This shouldn't have been included with the sample script. It was part of one of our demo scripts and not a function of UA. I've fixed the sample script.

authors: Windos adamdriscoll

repo: ironmansoftware/universal-automation

license: MIT


text:
Revamp index subscription for Leaflet map

The subscription isn't really working as intended, as giveaways added or removed sometimes don't reflect on the map.
I would suggest that the map make use of the giveaways-search publication, which should publish all items that would appear in the current tab in the timeline.
This should be left for later.

Okay, wasn't that difficult to implement, but was required because of #51.


text:
Returning rowcount of expanded rows

Promised PR. Fixed scrolling height - row count now returns the count of visible rows instead of all rows.
You can consider merging your branch with upstream master, so possible owner sees that PR is at least auto-merging and in buildable state.

Thanks!

source: gharchive/pull-request

authors: dlorych isaacplmann


text:
N1QL support (improved version)

This PR builds on top of what @andrestaht started in #1279
Added required documentation and made the auto-detections tests pass.
Tuned the definition in several ways:

Increase relevance of INFER, UPSERT, MISSING and backquoted identifiers.
Remove support for -- and  $ comments
Highlight backquoted-strings as symbols - they really are identifiers not strings.

Merged. Sorry for the long wait [insert standard busy maintainer apology]. Thanks for the contribution!

authors: isagalaev nene


text:
[mdbx_sys] README.md and build.rs to fix Windows build

This pull request updates the following files in the mdbx_sys package:

Add README.md which explains steps to properly build the package on Windows for Rust Development.
Minor update to build.rs to fix build errors on Windows: Specifically, the new script introduces workarounds to solve:

bindgen incompatibility with clang (#2500), and
-D MDBX_LOCK_SUFFIX was properly configured for Windows build through CMake. This could potentially result in undefined behavior in Windows since the isar logic (e.g., IsarInstance::close_internal) is hard-coded to depend on the suffix .lock.

Minor update to packages/isar/README.md 😀!

Note: This an updated pull request of the amended #87 (because directory structure mistake)

@vicenterusso Do you have an idea why the github action workflow did not build this pull request?

@vicenterusso Do you have an idea why the github action workflow did not build this pull request?

No clue, maybe because it was marked as a draft? just guessing..

authors: mrclauss psengrith vicenterusso

repo: isar-community/isar


text:
"libisar.so" not found

Steps to Reproduce
I periodically send a local push notification in my application and initialize Isar to get some data for notification content. Most of the time there is no error but yesterday Firebase reported 24 crashes at the same device and same time.
Code sample
Sending local push notification with Work Manager:
@pragma('vm:entry-point')
void callbackDispatcher() {
  Workmanager().executeTask((task, inputData) async {
    try {
      final appDatabase = await AppDatabase.initialize();
      final appNotification = await AppLocalNotificationController.initialize();
      final word = await appDatabase.wordDao().getRandomWord();
      await appNotification.showWordNotification(entity: word);
    } on Exception catch (e) {
      print(e);
    }
    return Future.value(true);
  });
}

Isar Initialization:
 _init() async {
    final path = await getAppDatabasePath();
    isar = await Isar.open([
      ...schemes
    ], name: "APP_DATABASE", directory: path);
  }

  static Future<String> getAppDatabasePath() async {
    final dir = Directory(
        '${(Platform.isAndroid ? await getExternalStorageDirectory() //FOR ANDROID
                : await getApplicationSupportDirectory() //FOR IOS
            )!.path}/database');
    if ((await dir.exists())) {
      return dir.path;
    } else {
      dir.create();
      return dir.path;
    }
  }

Details

Platform: Samsung A32 - Android 13
Flutter version: 3.3.10
Isar version: 3.0.5

Log

Show logs
Fatal Exception: java.lang.RuntimeException: Unable to get provider androidx.startup.InitializationProvider: s.c: java.lang.UnsatisfiedLinkError: dlopen failed: library "libisar.so" not found
     at android.app.ActivityThread.installProvider(ActivityThread.java:8312)
     at android.app.ActivityThread.installContentProviders(ActivityThread.java:7812)
     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7561)
     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(ActivityThread.java)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2397)
     at android.os.Handler.dispatchMessage(Handler.java:106)
     at android.os.Looper.loopOnce(Looper.java:226)
     at android.os.Looper.loop(Looper.java:313)
     at android.app.ActivityThread.main(ActivityThread.java:8741)
     at java.lang.reflect.Method.invoke(Method.java)
     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

Caused by s.c: java.lang.UnsatisfiedLinkError: dlopen failed: library "libisar.so" not found
     at androidx.startup.AppInitializer.doInitialize(AppInitializer.java:101)
     at androidx.startup.AppInitializer.discoverAndInitialize(AppInitializer.java:82)
     at androidx.startup.AppInitializer.discoverAndInitialize(AppInitializer.java:36)
     at androidx.startup.InitializationProvider.onCreate(InitializationProvider.java:16)
     at android.content.ContentProvider.attachInfo(ContentProvider.java:2522)
     at android.content.ContentProvider.attachInfo(ContentProvider.java:2492)
     at android.app.ActivityThread.installProvider(ActivityThread.java:8307)
     at android.app.ActivityThread.installContentProviders(ActivityThread.java:7812)
     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7561)
     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(ActivityThread.java)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2397)
     at android.os.Handler.dispatchMessage(Handler.java:106)
     at android.os.Looper.loopOnce(Looper.java:226)
     at android.os.Looper.loop(Looper.java:313)
     at android.app.ActivityThread.main(ActivityThread.java:8741)
     at java.lang.reflect.Method.invoke(Method.java)
     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

Caused by java.lang.UnsatisfiedLinkError: dlopen failed: library "libisar.so" not found
     at java.lang.Runtime.loadLibrary0(Runtime.java:1077)
     at java.lang.Runtime.loadLibrary0(Runtime.java:998)
     at java.lang.System.loadLibrary(System.java:1661)
     at dev.isar.isar_flutter_libs.IsarInitializer.create(IsarInitializer.java:8)
     at dev.isar.isar_flutter_libs.IsarInitializer.create(IsarInitializer.java)
     at androidx.startup.AppInitializer.doInitialize(AppInitializer.java:85)
     at androidx.startup.AppInitializer.discoverAndInitialize(AppInitializer.java:82)
     at androidx.startup.AppInitializer.discoverAndInitialize(AppInitializer.java:36)
     at androidx.startup.InitializationProvider.onCreate(InitializationProvider.java:16)
     at android.content.ContentProvider.attachInfo(ContentProvider.java:2522)
     at android.content.ContentProvider.attachInfo(ContentProvider.java:2492)
     at android.app.ActivityThread.installProvider(ActivityThread.java:8307)
     at android.app.ActivityThread.installContentProviders(ActivityThread.java:7812)
     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7561)
     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(ActivityThread.java)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2397)
     at android.os.Handler.dispatchMessage(Handler.java:106)
     at android.os.Looper.loopOnce(Looper.java:226)
     at android.os.Looper.loop(Looper.java:313)
     at android.app.ActivityThread.main(ActivityThread.java:8741)
     at java.lang.reflect.Method.invoke(Method.java)
     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

FinalizerDaemon:
     at java.lang.Object.wait(Object.java)
     at java.lang.Object.wait(Object.java:442)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:203)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:224)
     at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:300)
     at java.lang.Daemons$Daemon.run(Daemons.java:140)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Blocking Thread #0:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
     at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:463)
     at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
     at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:939)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Blocking Thread #1:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
     at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:463)
     at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
     at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:939)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Background Thread #0:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
     at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

firebase-installations-executor-2:
     at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
     at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
     at java.net.SocketInputStream.read(SocketInputStream.java:173)
     at java.net.SocketInputStream.read(SocketInputStream.java:143)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(ConscryptEngineSocket.java)
     at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:241)
     at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:220)
     at com.android.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:196)
     at com.android.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:153)
     at com.android.okhttp.internal.io.RealConnection.connect(RealConnection.java:116)
     at com.android.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:186)
     at com.android.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:128)
     at com.android.okhttp.internal.http.StreamAllocation.newStream(StreamAllocation.java:97)
     at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:289)
     at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:232)
     at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:465)
     at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:131)
     at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:262)
     at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getOutputStream(DelegatingHttpsURLConnection.java:219)
     at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:30)
     at com.google.firebase.installations.remote.FirebaseInstallationServiceClient.writeRequestBodyToOutputStream(FirebaseInstallationServiceClient.java)
     at com.google.firebase.installations.remote.FirebaseInstallationServiceClient.writeFIDCreateRequestBodyToOutputStream(FirebaseInstallationServiceClient.java:8)
     at com.google.firebase.installations.remote.FirebaseInstallationServiceClient.createFirebaseInstallation(FirebaseInstallationServiceClient.java:53)
     at com.google.firebase.installations.FirebaseInstallations.registerFidWithServer(FirebaseInstallations.java:47)
     at com.google.firebase.installations.FirebaseInstallations.doNetworkCallIfNecessary(FirebaseInstallations.java:34)
     at com.google.firebase.installations.FirebaseInstallations.lambda$doRegistrationOrRefresh$3(FirebaseInstallations.java)
     at com.google.firebase.installations.FirebaseInstallations.$r8$lambda$Kl2wdAe5utVajeTmV5LyfWUz3Bo(FirebaseInstallations.java)
     at com.google.firebase.installations.FirebaseInstallations$$InternalSyntheticLambda$1$b9fc2c28ef307c94a05f9f2ca9baa5bd46434e43c62d588972a9d84cceb0aed2$0.run(FirebaseInstallations.java:4)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at java.lang.Thread.run(Thread.java:1012)

ReferenceQueueDaemon:
     at java.lang.Object.wait(Object.java)
     at java.lang.Object.wait(Object.java:442)
     at java.lang.Object.wait(Object.java:568)
     at java.lang.Daemons$ReferenceQueueDaemon.runInternal(Daemons.java:232)
     at java.lang.Daemons$Daemon.run(Daemons.java:140)
     at java.lang.Thread.run(Thread.java:1012)

FinalizerWatchdogDaemon:
     at java.lang.Object.wait(Object.java)
     at java.lang.Object.wait(Object.java:442)
     at java.lang.Object.wait(Object.java:568)
     at java.lang.Daemons$FinalizerWatchdogDaemon.sleepUntilNeeded(Daemons.java:385)
     at java.lang.Daemons$FinalizerWatchdogDaemon.runInternal(Daemons.java:365)
     at java.lang.Daemons$Daemon.run(Daemons.java:140)
     at java.lang.Thread.run(Thread.java:1012)

pool-8-thread-1:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
     at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at java.lang.Thread.run(Thread.java:1012)

Crashlytics Exception Handler1:
     at dalvik.system.VMStack.getThreadStackTrace(VMStack.java)
     at java.lang.Thread.getStackTrace(Thread.java:1841)
     at java.lang.Thread.getAllStackTraces(Thread.java:1909)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsReportDataCapture.populateThreadsList(CrashlyticsReportDataCapture.java:16)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsReportDataCapture.populateExecutionData(CrashlyticsReportDataCapture.java:4)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsReportDataCapture.populateEventApplicationData(CrashlyticsReportDataCapture.java:45)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsReportDataCapture.captureEventData(CrashlyticsReportDataCapture.java:44)
     at com.google.firebase.crashlytics.internal.common.SessionReportingCoordinator.persistEvent(SessionReportingCoordinator.java:19)
     at com.google.firebase.crashlytics.internal.common.SessionReportingCoordinator.persistFatalEvent(SessionReportingCoordinator.java:32)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsController$2.call(CrashlyticsController.java:49)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsController$2.call(CrashlyticsController.java)
     at com.google.firebase.crashlytics.internal.common.CrashlyticsBackgroundWorker$3.then(CrashlyticsBackgroundWorker.java:2)
     at com.google.android.gms.tasks.zze.run(zze.java:8)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(ExecutorUtils.java:2)
     at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(BackgroundPriorityRunnable.java:5)
     at java.lang.Thread.run(Thread.java:1012)

GmsDynamite:
     at java.lang.Object.wait(Object.java)
     at java.lang.Object.wait(Object.java:442)
     at java.lang.Object.wait(Object.java:568)
     at com.google.android.gms.dynamite.zza.run(zza.java:6)

ScionFrontendApi:
     at mc.<init>(mc.java:1)
     at iw.<init>(iw.java:27)
     at iw.h(iw.java:4)
     at com.google.android.gms.measurement.internal.AppMeasurementDynamiteService.initialize(AppMeasurementDynamiteService.java:2)
     at dh.a(dh.java:184)
     at al.onTransact(al.java:4)
     at android.os.Binder.transact(Binder.java:1200)
     at com.google.android.gms.internal.measurement.zzbm.zzc(zzbm.java:7)
     at com.google.android.gms.internal.measurement.zzca.initialize(zzca.java:14)
     at com.google.android.gms.internal.measurement.zzcx.zza(zzcx.java:129)
     at com.google.android.gms.internal.measurement.zzdu.run(zzdu.java:12)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Blocking Thread #2:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
     at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:463)
     at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
     at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:939)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

OkHttp ConnectionPool:
     at java.lang.Object.wait(Object.java)
     at com.android.okhttp.ConnectionPool$1.run(ConnectionPool.java:106)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at java.lang.Thread.run(Thread.java:1012)

com.google.firebase.crashlytics.startup1:
     at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
     at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
     at java.net.SocketInputStream.read(SocketInputStream.java:173)
     at java.net.SocketInputStream.read(SocketInputStream.java:143)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.readFromSocket(ConscryptEngineSocket.java:945)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:909)
     at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(ConscryptEngineSocket.java)
     at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:241)
     at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:220)
     at com.android.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:196)
     at com.android.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:153)
     at com.android.okhttp.internal.io.RealConnection.connect(RealConnection.java:116)
     at com.android.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:186)
     at com.android.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:128)
     at com.android.okhttp.internal.http.StreamAllocation.newStream(StreamAllocation.java:97)
     at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:289)
     at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:232)
     at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:465)
     at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:131)
     at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.connect(DelegatingHttpsURLConnection.java:90)
     at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:30)
     at com.google.firebase.crashlytics.internal.network.HttpGetRequest.execute(HttpGetRequest.java:95)
     at com.google.firebase.crashlytics.internal.settings.DefaultSettingsSpiCall.invoke(DefaultSettingsSpiCall.java:60)
     at com.google.firebase.crashlytics.internal.settings.SettingsController$1.then(SettingsController.java:13)
     at com.google.firebase.crashlytics.internal.settings.SettingsController$1.then(SettingsController.java:2)
     at com.google.android.gms.tasks.zzo.run(zzo.java:12)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(ExecutorUtils.java:2)
     at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(BackgroundPriorityRunnable.java:5)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Blocking Thread #3:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
     at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:463)
     at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
     at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:939)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

firebase-installations-executor-1:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
     at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:458)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at java.lang.Thread.run(Thread.java:1012)

Firebase Background Thread #1:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
     at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.concurrent.CustomThreadFactory.lambda$newThread$0(CustomThreadFactory.java:12)
     at com.google.firebase.concurrent.CustomThreadFactory.$r8$lambda$25wFMnJXuxCXflRCTG3ggSOiDOE(CustomThreadFactory.java)
     at com.google.firebase.concurrent.CustomThreadFactory$$InternalSyntheticLambda$1$b6fa154e7b354bc98bdc1665fd14dc6fa8b0a872d08e8553325bb3034a0f4e42$0.run(CustomThreadFactory.java:4)
     at java.lang.Thread.run(Thread.java:1012)

awaitEvenIfOnMainThread task continuation executor1:
     at jdk.internal.misc.Unsafe.park(Unsafe.java)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
     at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
     at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(ExecutorUtils.java:2)
     at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(BackgroundPriorityRunnable.java:5)
     at java.lang.Thread.run(Thread.java:1012)

[x] I searched for similar issues already
[x] I filled the details section with the exact device model and version

(Duplicate of https://github.com/isar/isar/issues/1080?)

This is fixed in v3.1.0 which will be available soon on pub.dev.

authors: JaffaKetchup ekrmh simc

repo: isar/isar


text:
Update Sample App Url Link.

Updated Sample Url link from https://github.com/isar/samples to https://github.com/isar/isar/tree/main/examples/.

Thanks 🙏


text:
是否考虑支持自定义短链地址？

RT，个人想做一个简短 Tags 快速跳转自己项目文档什么地址的短链 Url，需要自定义地址的功能

可以嗷，安排。

已完成接口部分实现，页面的自定义短链的样式还需要调一下。

authors: Dreamer-Paul isecret

repo: isecret/short


text:
improving styling

under the services section there is 4 blocks all of there length are not same some level is up some are down

@leesha19 go ahead!

In health bliss highlights can i add more section like helping others, excercise or involving in activities?

In health bliss highlights can i add more section like helping others, exercise or involving in activities?

Of course! but please open an issue for the same.

Can I work here?


text:
Fix helper function references

Based on #77 I modified the tool that generates the references to first sort them, then remove any duplicates. I also fixed a copy-paste mistake in the data file which was causing the missing bpf_tcp_raw_gen_syncookie_ipv4 helper reference for XDP programs.
@MahnurA could you verify this is fixes the duplicates you spotted?

Yes, all duplicates are gone.

authors: MahnurA dylandreimerink

repo: isovalent/ebpf-docs


text:
Clarity on Universal Machines

Hello Sandy, first I must appreciate you for taking the time to write the book you have on your blog. I write technical articles, so I know it's not an easy feat - writing a book is much more.
Reading your book has helped unblock in a book (Computer Science Distilled) I was reading. I created this issue to seek clarity on what you have on Universal Machines, where you wrote about combining logic gates.
I've been having a hard time figuring out how you arrived at the outputs for the combined logic gates below;

Since I was a beginner on this topic I decided to learn more in order to fill up necessary gaps so I could understand what you were doing. However, that didn't help me arrive at the same result you had. Here is what I was able to come up with.

I was wondering if you could help explain or point me to what I am missing or give me some sort of hints.
Thanks.

I think you might have found an error in the book; I was trying to write a chapter a day, and, IIRC, that section had some issues I never got around to fixing (assuming, apparently incorrectly, that nobody would ever read this thing.)
As it happens, I'm actively working on an entire rewrite of the book; building the entire machine, and with a computer-verified implementation to ensure problems like these don't spring up.
Thanks for reading, and for the bug report --- sorry to have wasted your time trying to understand a mistake in the source text!

I find it hard to think about this stuff, so I ran the examples through my new verifier, and I get these results. For the first machine (first' notGate >>> andGate >>> notGate), the truth table is
(1, 0) -> 1
(1, 1) -> 1
(0, 1) -> 0
(0, 0) -> 1

and for the one with not gates on either input wire (both notGate >>> andGate >>> notGate):
(1, 1) -> 1
(1, 0) -> 1
(0, 0) -> 0
(0, 1) -> 1

which means the tables as given in the book are correct. So what's going on?
In your first diagram, we get the same truth tables. In the second, you are forgetting a not gate where Z is :)

Yeah, that's true, I'm forgetting the last not gate. Thanks for pointing that out.
However, in the first composed logic gates, it looks like your truth table swaps the output of 1, 1 with the output of 0, 1. This is different from what you have in the response you have above, where the output of 1, 1 is 1 and the output of 0, 1 is 0. Is that correct?

Also, I'm curious to know if/how I can help out in the current rewrite. The linked repo seems to use Haskell, I have no experience with it though.

I don't see the discrepancy you're trying to point me towards, sorry! In this table:

in the leftmost column, there are crossed out values with an arrow towards new values. The crossed out values are the inputs as they were before introducing the not gate on the A input. After putting the not gate there, the rest of the circuit stays the same; all that changes is the "effective" A input to the circuit. This new effective input is described with an arrow pointing at the NOT of the old value.
That is to say, if we're looking at ~1~ -> 0, the effective input to the circuit is 0.
In the table I gave above:
(1, 0) -> 1
(1, 1) -> 1
(0, 1) -> 0
(0, 0) -> 1

I unwisely decided to use the same arrow notation to mean something different. Here, this should be read as (A, B) -> Output. When looking at this truth table, it's the same as both the table given in the book (when looking at the effective input A), and it's also the same as your truth table (though our rows are in different orders.)
Does that help? Am I still missing something?

I'm curious to know if/how I can help out in the current rewrite.

That's an extremely generous offer, thank you @kinsomicrote! At this point in time, you are more familiar with the book as it exists today than I am; perhaps the most help you can be right now is to file bugs for anything that isn't immediately clear. If a concept or paragraph takes more than 5 minutes to do, it's probably because I am bad at writing, and that's the sort of stuff I can't check for myself. I'm extremely grateful for this bug report, and for any others you might think to send my way!

The linked repo seems to use Haskell, I have no experience with it though.

If you're looking for a life-changing experience, learning Haskell will dramatically change the way you think about software.

authors: isovector kinsomicrote


text:
chore: Update dependencies.

This causes an update to mem to resolve a potential DoS vulnerability in
command-line processing.
The vulnerable version of mem is still included by development
dependencies.
Fixes #918

Will this PR be merged?

Any chance of a new npm release that includes this PR? The new version of yargs includes a fix for a security issue.

It seems this PR broke the build for Node 6, affecting commit after it and pull request.
https://travis-ci.org/istanbuljs/nyc/builds
https://travis-ci.org/istanbuljs/nyc/builds/456881459
# Subtest: wraps modules with coverage counters when the custom require hook compiles them
    not ok 1
- expected 270
+ to equal 267

authors: Krinkle coreyfarrell popomore watson

repo: istanbuljs/nyc

license: isc


text:
#60 Added TypeScript recipe

Added typescript recipe for issue #60 "Add TypeScript docs / recipe"
How do handle translations,  you go with google translate until someone makes a better translation or do you have a specific process?

Already in master

repo: isthatcentered/website


text:
Don't rename doc.go since it's expected by k8s code generator

Currently fake client-go client sets are broken, e.g. we have[1]
var gatewaysResource = schema.GroupVersionResource{Group: "networking", Version: "v1alpha3", Resource: "gateways"}
which should really be
var gatewaysResource = schema.GroupVersionResource{Group: "networking.istio.io", Version: "v1alpha3", Resource: "gateways"}
This is because

kubetype-gen generated apis are missing groupName comment tag (addressed by istio/tools#549)
k8s code generator expects groupName comment tag to be in doc.go but it is currently getting renamed to doc.gen.go

This change fixes 2.
[1] https://github.com/istio/client-go/blob/21751e6cf0fea131872230940d95c40508aa0a4f/pkg/clientset/versioned/typed/networking/v1alpha3/fake/fake_gateway.gen.go#L21

Hi @skaslev. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

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

/assign @jwendell

@skaslev do you a test/example you can add that verifies fake client, we can make sure that code compiles as part of the CI process so this doesn't break again.
Please also cherry-pick this to release-1.4 branch. Thanks!

/ok-to-test

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

Test name
Commit
Details
Rerun command

gencheck_client-go
c5238ec42698f78ed44341303071ee7aa936a070
link
/test gencheck_client-go

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

@skaslev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_client-go
c5238ec42698f78ed44341303071ee7aa936a070
link
/test gencheck_client-go

lint_client-go
1311251d9616283b3d4fd9ab7aff10dc3e81b26d
link
/test lint_client-go

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

@skaslev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

lint_client-go
1311251d9616283b3d4fd9ab7aff10dc3e81b26d
link
/test lint_client-go

gencheck_client-go
1311251d9616283b3d4fd9ab7aff10dc3e81b26d
link
/test gencheck_client-go

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

@skaslev do you a test/example you can add that verifies fake client, we can make sure that code compiles as part of the CI process so this doesn't break again.

I don't have one atm. This was noticed while migrating Knative to use istio.io/client-go instead of its own apis for istio, see knative/serving#6041. Some of Knative tests were hanging and the informer was logging errors when using the fake clientset.
I'll try to think of a good test for this.

Please also cherry-pick this to release-1.4 branch.

Will do. Is there a documentation of the process how to do that?

Will do. Is there a documentation of the process how to do that?

Yes, you just need to add the label "cherry-pick/release-1.4" to your PRs. I'm not sure if you're allowed to do that if you're not a member, give it a try. If it doesn't work I can do it for you.

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

Test name
Commit
Details
Rerun command

gencheck_client-go
8b0920022172098f99a0aef56b4711b7eb1afed9
link
/test gencheck_client-go

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

/hold
There are two issues with this PR:

gencheck_client-go is failing because its using kubetype-gen before istio/tools#549 got merged. Probably some container image should be updated before merging this?
lint_client-go is failing because new kubetype-gen generated doc.go have no license header and doc.gen.go were ignored by lint-copyright-banner. I can either make target lint-copyright-banner in Makefile.common.mk from https://github.com/istio/common-files ignore doc.go files, or have kubetype-gen output copyright header for doc.go files. Suggestions?

cc @jwendell @nrjpoddar

@skaslev you would need to manually run make update-common to grab the latest common files., until we automate this process. @geeknoid FYI.

@skaslev you would need to manually run make update-common to grab the latest common files., until we automate this process. @geeknoid FYI.

Sure, waiting on istio/common-files#149 to get merged first.

@skaslev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_client-go
8b0920022172098f99a0aef56b4711b7eb1afed9
link
/test gencheck_client-go

lint_client-go
abd50007e9b5997faa5bfbdc4ef353a445d5578d
link
/test lint_client-go

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

@skaslev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

lint_client-go
abd50007e9b5997faa5bfbdc4ef353a445d5578d
link
/test lint_client-go

gencheck_client-go
abd50007e9b5997faa5bfbdc4ef353a445d5578d
link
/test gencheck_client-go

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

The image in test-infra also need to be changed.

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

Test name
Commit
Details
Rerun command

gencheck_client-go
cf3adeadea42d0b069156eb97fe8deae12cdf8b6
link
/test gencheck_client-go

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

Since istio/common-files#149 is being pushed back, I changed header.go.txt so now all k8s client generated files have a copyright notice.
As @jasonwzm mentioned, for gencheck_client-go to pass the image in test-infra needs to be pushed and updated but I don't think I have permissions for this.

Since istio/common-files#149 is being pushed back, I updated header.go.txt so now all k8s client generated files have copyright banners.
As @jasonwzm mentioned, for gencheck_client-go to pass the image in test-infra needs to be pushed and updated with latest istio/tools but I don't think I have permissions for this.

@skaslev please submit a PR to test-infra to make the change. Anyone has permission to submit a PR.  If the PR is acceptable to the T&R reviewers, the PR will be merged pretty quickly.
I would help out here, but I am boarding a plane in a few hours and really busy for the next few days.
Modify this line: https://github.com/istio/test-infra/blob/master/prow/config/jobs/client-go.yaml#L4
with the latest image from:
https://console.cloud.google.com/gcr/images/istio-testing/GLOBAL/build-tools?gcrImageListsize=30
which happens to have the tag:
master-2019-11-15T13-58-33
After that change to istio/test-infra, in the TLD run make gen.  This will convert the client-go.yaml prow human-readable config into prow-less-human-readable parsed output.
You should end up with two files changed in your PR.  Push when ready.
I will review if you like.  Pass the information along 😀
Cheers
-steve

Thank for the help @sdake! Just sent istio/test-infra#2108 for review.

/retest

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

Test name
Commit
Details
Rerun command

gencheck_client-go
cf3adeadea42d0b069156eb97fe8deae12cdf8b6
link
/test gencheck_client-go

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

/hold cancel

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

Test name
Commit
Details
Rerun command

gencheck_client-go
820f8f934548d22c4cc4b92212b998fe5807123d
link
/test gencheck_client-go

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

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

Test name
Commit
Details
Rerun command

gencheck_client-go
d884deceff940d07c29b7dff945df5f75d8a62f2
link
/test gencheck_client-go

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

@geeknoid can you review this PR?
The only functional change is in this commit, everything else is auto generated.

@skaslev Thanks for making the change! A manual cherrypick is probably needed to 1.4.

authors: istio-testing jasonwzm jwendell nrjpoddar sdake skaslev

repo: istio/client-go


text:
Update to apps/v1

These are using deprecated APIs that will be removed in k8s 1.16, which will release the same time we release istio 1.3
See istio/istio/issues/12211

@howardjohn: PR needs rebase.

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

authors: howardjohn istio-testing

repo: istio/cni


text:
Revert the PR 1744 as the yaml files have been added back

The PR 1744 fixes the non-existent yaml files in the description of Citadel health checking in
https://preliminary.istio.io/docs/tasks/security/health-check.html reported by the issue https://github.com/istio/istio/issues/6922. Since the PR https://github.com/istio/istio/pull/7178 adds back the removed yaml files, the PR 1744 is reverted.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: lei-tang
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: sdake
If they are not already assigned, you can assign the PR to them by writing /assign @sdake in a comment when ready.
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:

content/OWNERS

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

/cc @wattli

/cc @ymesika

/cc @myidpt

/assign @sdake

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: lei-tang, sdake
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:

content/OWNERS [sdake]

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

Just noticed the linter failed in many areas - can you resolve?
TIA
-steve

authors: istio-testing lei-tang sdake


text:
Write EPIPE Error or read ECONNRESET error when using istio with cloudsql proxy sidecar

Describe the bug
I'm using GCK, and I have a pod that runs an application along with both istio and cloudsql proxy sidecar. The application can successfully access database but always gets the following errors in the application logs. Any ideas how to solve this error ?
Debug: internal, implementation, error
  Error: read ECONNRESET
  at TCP.onread (net.js:602:25)

Debug: internal, implementation, error
  Error: Uncaught error: write EPIPE
   at WriteWrap.afterWrite [as oncomplete] (net.js:844:14)

Cloudsql proxy runs with the following setup.
 containers:
      - image: b.gcr.io/cloudsql-docker/gce-proxy:latest
        imagePullPolicy: Always
        name: cloudsqlproxy
        command: ["/cloud_sql_proxy", "--dir=/cloudsql",
                "-instances=project-name:zone:db_name=tcp:0.0.0.0:5432",
                "-credential_file=$SECRET_FILE_PATH"]
        ports:
        - name: db_name
          containerPort: 5432

I also wrote the following ServiceEntry and VirtualService rules
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: https-network-rule
spec:
  hosts:
    - www.googleapis.com
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: cloud-sql-instance
spec:
  hosts:
    - $INSTANCE_IP_ADDRESS
  addresses:
    - $INSTANCE_IP_ADDRESS/32
  ports:
    - name: tcp
      number: 3307
      protocol: tcp
  location: MESH_EXTERNAL

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: google
spec:
  hosts:
    - www.googleapis.com
  tls:
  - match:
    - port: 443
      sniHosts:
      - www.googleapis.com
    route:
    - destination:
        host: www.googleapis.com

Version
k8s version - 1.11.2
Installation
Through the following gcloud command.
gcloud beta container clusters update istio-demo --project=$PROJECT_ID
--update-addons=Istio=ENABLED --istio-config=auth=MTLS_PERMISSIVE
Environment
Google cloud Kubernes

Those errors usually indicate that one side is doing TLS and the other is not.
I see you have configured port 5432 and your rule is for port 3307.  You might try adding TCP ports for 5432 and 3306.
I will often troubleshoot this by starting a pod with the mysql client in it and doing mysql -u dbuser -p<password> -h <host> -P3306 -e "show databases" interactively, tinkering with the Istio rules.

authors: esnible mkinoshi

repo: istio/istio


text:
Ingress only gets IP when it is in the istio-system namespace

@ijsnellf commented on Wed Sep 27 2017
The ingress status syncer tries to grab the IP from <discovery namespace>/<ingress service>. We watch for ingress definitions in either all namespaces, or a given user namespace.

@ijsnellf commented on Thu Sep 28 2017
Might only be in minikube... will verify.

@andraxylia commented on Thu Sep 28 2017
How is this different from #1021?
Why are the ingress resources definitions relevant to this? They do not participate in the setting of the IP address. Multiple ingress resources can be defined in multiple namespaces, and they will all get the ingress controller's external IP or nodePort.

@ijsnellf is this still an issue?

authors: andraxylia kyessenov


text:
Add metric server nanny config for perf cluster

The metric server is always dead on these clusters because it is scaled for 30pods/node (Not sure why...). We should specify our own config using https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#example-deployment-file. Its just a config map in kube-system.

starter:
cat <<EOF | kubectl apply -n kube-system -f -
apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    baseCPU: 100m
    baseMemory: 200Mi
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
EOF

not well tuned though

not stale


text:
Move Analysis Framework to Istiod

istioctl analyze can remain use the existing framework. Merge with distribution status controller is also good to have.

Any updates on this? Just wasted an hour digging through 100s of callbacks and async processes

Still WIP. You mean debugging the processing pipeline?

Yes, I am interested in this issue so we can delete all of this code and never have to debug it again :slightly_smiling_face:

I am hoping to do it soon. I will likely refocus on this later this week. Why do you have to do debug galley code? It is just running analysis.

https://github.com/istio/istio/issues/25893 is the issue

ok. do you have an idea on how to fix it or you are waiting for the code to be removed.

not stale
On Sun, Oct 25, 2020 at 12:02 PM Istio Policy Bot notifications@github.com
wrote:

🧭 This issue or pull request has been automatically marked as stale
because it has not had activity from an Istio team member since 2020-07-27.
It will be closed on 2020-11-09 unless an Istio team member takes action.
Please see this wiki page
https://github.com/istio/istio/wiki/Issue-and-Pull-Request-Lifecycle-Manager
for more information. Thank you for your contributions.
Created by the issue and PR lifecycle manager.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/23943#issuecomment-716195204, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXMQCOYIASUAKBA4LX3SMRY4VANCNFSM4NEM4U3Q
.

is this planned for 1.9?

No, likely 1.10, design in 1.9.

Not stale
On Tue, Sep 21, 2021 at 10:01 PM Istio Policy Bot @.***>
wrote:

🧭 This issue or pull request has been automatically marked as stale
because it has not had activity from an Istio team member since 2021-06-23.
It will be closed on 2021-10-06 unless an Istio team member takes action.
Please see this wiki page
https://github.com/istio/istio/wiki/Issue-and-Pull-Request-Lifecycle-Manager
for more information. Thank you for your contributions.
Created by the issue and PR lifecycle manager.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/23943#issuecomment-924585251, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXIWRORI5IPVFKCYFFLUDFPKRANCNFSM4NEM4U3Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

this is done!

authors: howardjohn jasonwzm


text:
Not able to load balance gRPC Client Request using Istio

I am unable to load balance the gRPC requests where my Client and Server applications are both Istio Injected.
Istio Version: 1.7.2
Scenario:
gRPC-Server is an Istio service having multiple Pods in Kubernetes Cluster.
gRPC-Client is another Istio service having single Pod in Kubernetes Cluster.
gRPC-Client calls gRPC-Server service using its Kubernetes ServiceName and ServicePort.
Virtual Service and Destination Rule is also created for gRPC-Server service.
Expected Behavior:
Request calls from gRPC-Client must land on all available gRPC-Server pods in round robin fashion.
Actual Behavior:
The request call every time lands on same gRPC-Server pod only.
Following is the gRPC-Server Service Yaml file:
grpc-server-svc-yaml.txt
Following is the gRPC-Server Virtual Service and Destination Rule file:
grpc-server-vs-dr-yaml.txt
If I route the request via any other Envoy based application like Ambassador then load balancing is done perfectly.
As Istio is also based on Envoy, load balancing must also be done seamlessly.

This is in port 6565 right?
It looks like your subset labels and pod labels do not match.

Yes, the port is 6565.
Can it work without creating Virtual Service and Destination Rule for gRPC-Server service?
I tried but in vain.

it should work without vs and Dr, but if you create invalid ones it may
make thing not work as expected
On Tue, Sep 29, 2020, 7:14 AM safvankothawala notifications@github.com
wrote:

Yes, the port is 6565.
Can it work without creating Virtual Service and Destination Rule for
gRPC-Server service?
I tried but in vain.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/27621#issuecomment-700733741, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXK4RX464NRNZRJ5OL3SIHTT5ANCNFSM4R5ZQYIQ
.

Hello,
I recreated all the k8s artifacts and then it worked !!
I also applied timeout using VS/DR and it also worked fine.
Just to confirm, is it mandatory to make a gRPC-Server k8s svc a Headless Service or it can be a NodePort or ClusterIP service also?

It can be a clusterip as well. glad its working now!

Hi, I am observing this while trying to hit grpc, when I try to connect using grpc-headless.default.svc.cluster.local:50051 it works but when I use route grpc-headless.default.svc.cluster.local it fails
Error: 14 UNAVAILABLE: upstream connect error or disconnect/reset before headers. reset reason: connection failure
    at Object.exports.createStatusError (/usr/src/app/node_modules/grpc/src/common.js:91:15)
    at Object.onReceiveStatus (/usr/src/app/node_modules/grpc/src/client_interceptors.js:1209:28)
    at InterceptingListener._callNext (/usr/src/app/node_modules/grpc/src/client_interceptors.js:568:42)
    at InterceptingListener.onReceiveStatus (/usr/src/app/node_modules/grpc/src/client_interceptors.js:618:8)
    at callback (/usr/src/app/node_modules/grpc/src/client_interceptors.js:847:24)

here is my config  for virutal service and headless
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: route-grpc
spec:
  hosts:
  - grpc-headless.default.svc.cluster.local
  http:
  - name: "grpc"
    route:
    - destination:
        host: grpc-headless.default.svc.cluster.local
        subset: v1
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: destination-grpc
spec:
  host: grpc-headless.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      app: grpc-headless
      version: v1
---

apiVersion: v1
kind: Service
metadata:
labels:
app: grpc-headless
version: v1
name: grpc-headless
spec:
clusterIP: None
ports:

name: grpc
port: 50051
protocol: TCP
targetPort: 50051
selector:
app: grpc
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}

this is a describe of the service with istio sidecar

when I try to connect using grpc-headless.default.svc.cluster.local:50051 it works but when I use route grpc-headless.default.svc.cluster.local it fails

This seems expected? You need to connect to the correct port?

I'm experiencing the same behaviour, there is request every 5 seconds and it always lands in the same pod.
Here is the deploying configuration https://github.com/alexsotocx/go-grpc-test/blob/main/deployment.yaml
And here  are the apps

Client: https://github.com/alexsotocx/go-grpc-test/tree/main/client
Server: https://github.com/alexsotocx/go-grpc-test/tree/main/server

For the sake of the experiment I created  3 deployments

Client, 1 Pod pointing to the grpc-server.namespace.svc.cluster.local
Server 1, 1 pod with server name variable server-1111111
Server 2, 1 pod with server name variable server-22222

Here are the endpoints
➜  go-grpc-test git:(main) ✗ kubectl get endpoints grpc-server
NAME          ENDPOINTS                           AGE
grpc-server   10.15.1.230:8000,10.15.1.231:8000   11s
➜  go-grpc-test git:(main) ✗

➜  ~ k get services |grep grpc-server
grpc-server                  ClusterIP   10.16.14.60    <none>        8000/TCP   16m

➜  ~ k get virtualservices.networking.istio.io server
NAME     GATEWAYS   HOSTS                                            AGE
server              ["grpc-server.apps-staging.svc.cluster.local"]   16m
➜  ~

➜  ~ kubectl get pods -l app=server
NAME                       READY   STATUS    RESTARTS   AGE
server1-7dcd87d74-6h7sv    2/2     Running   0          17m
server2-647cbf5b84-z6n2k   2/2     Running   0          17m
➜  ~ kubectl get pods -l app=client
NAME                     READY   STATUS    RESTARTS   AGE
client-79575657b-lw7t9   2/2     Running   1          17m
➜  ~

I have destroyed and recreated everything but the same...

Here the logs

➜  ~ k logs -f client-68c76c76c-r46dv
2021/06/30 14:38:14 Connecting to server on grpc-server.apps-staging.svc.cluster.local:8000
2021/06/30 14:38:19 Response from server Hello, from grpc-server-222222
2021/06/30 14:38:24 Response from server Hello, from grpc-server-222222
2021/06/30 14:38:29 Response from server Hello, from grpc-server-222222
2021/06/30 14:38:34 Response from server Hello, from grpc-server-222222

Is there anything i'm missing?

Hello there, for people landing on this post,  I managed to find the root cause,
When I installed istio, the configuration for global.proxy.excludeIPRanges: "10.0.0.0/8" it was covering also the pods inside our cluster hence the traffic to services and pods inside the cluster was bypassing the istio proxy, which basically disabled grpc load balancing.
You can read more here. https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/#direct-access-to-external-services

authors: M-A-N-I-S-H-K alexsotocx howardjohn safvankothawala