Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move setRumAccessToken out of SplunkRum.builder #795

Open
ber4444 opened this issue Apr 3, 2024 · 5 comments
Open

Move setRumAccessToken out of SplunkRum.builder #795

ber4444 opened this issue Apr 3, 2024 · 5 comments

Comments

@ber4444
Copy link

ber4444 commented Apr 3, 2024

We are rotating our Splunk token on a regular schedule per infosec recommendation. So the app is pulling the token from Firebase remote config. The issue is that right now we need to delay Splunk SDK initialization until the remote values are read (from the server or from disk cache, both of which are async operations). Please add a way to allow the Splunk SDK to be initialized without a token, let it accumulate events, and then when we later provide a token, it would send the cached events in a batch back to your Splunk instance.

@breedx-splk
Copy link
Contributor

Thanks @ber4444 yes this is a good idea. It will take some care to get built correctly, but I hope that leveraging the upstream disk-buffering might also be able to help here.

@ber4444
Copy link
Author

ber4444 commented Apr 10, 2024

We can use enableDiskBuffering, so ideally the way it would work:

  1. launch app with old, expired token, initialize sdk, buffer events to disk, upon receiving an error, keep the buffer alive
  2. relaunching the app with a new token will send all events from disk buffer

Is it how it already works?

@breedx-splk
Copy link
Contributor

breedx-splk commented Apr 11, 2024

We can use enableDiskBuffering, so ideally the way it would work:

  1. launch app with old, expired token, initialize sdk, buffer events to disk, upon receiving an error, keep the buffer alive
  2. relaunching the app with a new token will send all events from disk buffer

Is it how it already works?

I think so, yeah that's the general idea. There are default limits to be aware of, however -- both the amount of data stored on device storage and the number of export attempts per file (20 is the default, see FileSender).

Some of the disk buffering is likely to have changes as well as we move away from Zipkin and closer toward the upstream/OpenTelemetry based OTLP disk buffering solution.

@ber4444
Copy link
Author

ber4444 commented Apr 12, 2024

Thanks, and FileSender is package private so defaults cannot be overriden.

@breedx-splk
Copy link
Contributor

Thanks, and FileSender is package private so defaults cannot be overriden.

Oh yeah you're right. It looks like we haven't surfaced any of that configurability yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants