# Duplicate syslog events when using Okta SDK **URL:** \ **Category:** Questions\ **Created:** [March 27, 2020, 6:13pm UTC](https://devforum.okta.com/t/duplicate-syslog-events-when-using-okta-sdk/8630 "2020-03-27T18:13:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![robcurtis](https://avatars.discourse-cdn.com/v4/letter/r/a587f6/32.png) [@robcurtis](https://devforum.okta.com/u/robcurtis)\ **Post date:** [March 27, 2020, 6:13pm UTC](https://devforum.okta.com/t/duplicate-syslog-events-when-using-okta-sdk/8630/1 "2020-03-27T18:13:41Z")
I’m working on a small application to periodically pull the latest syslog events from Okta using the Java Okta SDK. The flow essentially goes something like this: 1. Create `com.okta.sdk.client.Client` object and pass it into a new `Runnable` task 2. Submit `Runnable` task to ScheduledExecutorService with 5 minute interval 3. For each execution of task: 1. Check to see if I have an existing `sinceTime` checkpoint. a. If I have a `sinceTime` checkpoint, use it to call `Client.getLogs(null, sinceTime, null, null, null)` b. If I don’t have a `sinceTime` checkpoint, use a default sinceTime to call `Client.getLogs(null, defaultSinceTime, null, null, null)` 2. For each event, process and note the `publishTime` 3. Store the last seen `publishTime` as my new `sinceTime` checkpoint For each execution of the `Runnable` task after the first (essentially whenever I call `Client.getLogs()` using the `publishTime` of the last seen log event for the `sinceTime` parameter), that previously-seen event (sometimes multiple previously-seen events if they all had `publishTime` values in the same second) gets repeated in the new `LogEventList`. Is there any way, using the Java Okta SDK, to avoid this repetition? Would I be able to enforce a strictly-greater-than-this-timestamp query by using the `filter` field instead of relying on `sinceTime` with its apparent greater-than-or-equal-to-this-timestamp behavior? Am I simply using the SDK incorrectly (should I be making a single `Client.getLogs()` call and then periodically attempting to get new events from the `LogEventList` stream? Any insight would be appreciated. Thanks in advance! ---
**Author:** ![phi1ipp](https://avatars.discourse-cdn.com/v4/letter/p/85f322/32.png) [@phi1ipp](https://devforum.okta.com/u/phi1ipp)\ **Post date:** [March 28, 2020, 10:39pm UTC](https://devforum.okta.com/t/duplicate-syslog-events-when-using-okta-sdk/8630/2 "2020-03-28T22:39:23Z")
I think your approach is valid, to the best of my knowledge it’s the only approach to get events based on their timestamp. Filter won’t be able to help you with timestamp (if I correctly understood your idea to use it for filtering based on time). Filter only supports subjects/objects/eventTypes [Filtering Events](https://developer.okta.com/docs/reference/api/system-log/#filtering-results) I also had some troubles with precise timestamp processing by Okta, where I’d present a `sinceTime`, but Okta would give me an event which happened before this time. Also events not being visible with log api immediately, only after a delay ---
**Author:** ![robcurtis](https://avatars.discourse-cdn.com/v4/letter/r/a587f6/32.png) [@robcurtis](https://devforum.okta.com/u/robcurtis)\ **Post date:** [March 30, 2020, 2:19pm UTC](https://devforum.okta.com/t/duplicate-syslog-events-when-using-okta-sdk/8630/3 "2020-03-30T14:19:21Z")
Updating to share what I learned through experimentation after posting this question. It appears the `LogEventList` object returned by the Okta SDK `Client` is intended to be a long-lived object. It implements the `Iterator` interface, but it is more than just a simple iterator. When you call `hasNext()`, if it doesn’t have anything cached it calls back to the Okta server to see if there are more. Thus, I’m updating my flow to be more like the following: 1. Create `com.okta.sdk.client.Client` object and pass it into a new `Runnable` task a. In the `Runnable` constructor, if I have a `sinceTime` checkpoint, use it to call `Client.getLogs(null, sinceTime, null, null, null)` b. If I don’t have a checkpoint, call `getLogs()` with a default value c. Keep a reference to the `LogEventList.iterator()` 2. Submit `Runnable` to a `ScheduledExecutorService` with a 5 minute interval 3. For each execution of the task: a. Loop through available events using `while ( logEventIterator.hasNext() )` b. Process each event and note the `publish` time c. Store the last seen `publish` time as my new checkpoint (just in case I need to shut down and restart) This method still results in me getting one or more duplicate records when I restart the process, but I no longer get duplicate records on every execution of my `Runnable` task. I have also found a way to dig into the Okta Java SDK and extract the `after` token that gets used on the REST API (and a way to use it to get a new `Iterator`), but I am a bit afraid of depending on that since it depends on the internal implementation of the SDK rather than on the “official” SDK APIs and I fear that a future update to the SDK could break my code. Any chance the Okta devs would consider updating the SDK API to allow acces to (and use of) the `after` toke for checkpointing? ---
**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\ **Post date:** [January 23, 2024, 11:00pm UTC](https://devforum.okta.com/t/duplicate-syslog-events-when-using-okta-sdk/8630/4 "2024-01-23T23:00:38Z")