Create Java Library #1
Comments
Closed
Merged
tasn
pushed a commit
that referenced
this issue
Jun 9, 2021
svix-onelson
added a commit
that referenced
this issue
Jun 13, 2023
## Motivation Workers that run for a long time uninterrupted can leak memory _very slowly_. ## Solution Running svix-server through [bytehound](https://github.com/koute/bytehound), grouping allocations by the "largest leak by backtrace" gives us: ``` #00 [svix-server] _start #1 [libc.so.6] __libc_start_main #2 [libc.so.6] 7f15c8e4dd8f #3 [svix-server] main #15 [svix-server] svix_server::main #16 [svix-server] tokio::runtime::scheduler::multi_thread::MultiThread::block_on #17 [svix-server] tokio::runtime::context::BlockingRegionGuard::block_on #18 [svix-server] svix_server::main::{{closure}} #19 [svix-server] <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll #20 [svix-server] svix_server::run_with_prefix::{{closure}} #21 [svix-server] <tokio::future::poll_fn::PollFn<F> as core::future::future::Future>::poll #22 [svix-server] svix_server::run_with_prefix::{{closure}}::{{closure}} #23 [svix-server] svix_server::core::webhook_http_client::WebhookClient::new #24 [svix-server] openssl::ssl::connector::SslConnector::builder #25 [svix-server] openssl::ssl::connector::ctx #26 [libssl.so.3] SSL_CTX_new_ex #27 [libssl.so.3] 7f15c95cd2fa #28 [libcrypto.so.3] EVP_CIPHER_fetch #29 [libcrypto.so.3] 7f15c93e95ad #30 [libcrypto.so.3] 7f15c93e8f57 #31 [libcrypto.so.3] 7f15c93204da #32 [libcrypto.so.3] 7f15c930116d #33 [libcrypto.so.3] 7f15c9301268 #34 [libcrypto.so.3] 7f15c92e1659 #35 [libcrypto.so.3] 7f15c933d455 #36 [libcrypto.so.3] 7f15c9317394 #37 [libcrypto.so.3] CRYPTO_zalloc #38 [libbytehound.so] malloc [api.rs:294] ``` It's possible there's a leak in OpenSSL, and a proper fix can come from updating the lib _however_ in this case, we're linking dynamically. Since dynamic linking means we have less control over which specific versions are used, I tried to mitigate the growth on our side too. This diff tries to avoid the unwanted memory growth by instantiating one `WebhookClient` when the worker starts, cloning it each time we need to hand it off to a future instead of letting each future instantiate one itself. Running a low reqs/sec workload through svix-server locally seems to show a (closer to) flat memory profile over the course of an hour.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Take a look at
regen_openapi.shand all of the files injavascriptandpythonto see how to generate from the openapi spec, configure the generator to not generate some of the files, and make it into a package.You can also look at https://github.com/etesync/etebase-java for how to create a java package. Though it's an Android package, which is a bit different to normal Java packages.
Keep the same API structure as there is in Python and JS (e.g.
dh.message.create()).The text was updated successfully, but these errors were encountered: