The Optimizely Feature Experimentation Java SDK batches decision and conversion events into a single payload before sending it to Optimizely. This is achieved through a new SDK component called the event processor.

Event batching has the advantage of reducing the number of outbound requests to Optimizely depending on how you define, configure, and use the event processor. It means less network traffic for the same number of Impression and conversion events tracked.

In the Java SDK, BatchEventProcessor provides implementation of the EventProcessor interface and batches events. You can control batching based on two parameters:

• Batch size – Defines the number of events that are batched together before sending to Optimizely Feature Experimentation.
• Flush interval – Defines the amount of time after which any batched events should be sent to Optimizely Feature Experimentation.

An event consisting of the batched payload is sent as soon as the batch size reaches the specified limit or flush interval reaches the specified time limit. BatchEventProcessor options are described in more detail below.

📘

Note

Event batching works with both out-of-the-box and custom event dispatchers.

The event batching process does not remove any personally identifiable information (PII) from events. You must ensure that you are not sending any unnecessary PII to Optimizely.

Basic example

If you want to use the default configuration of BatchEventProcessor (with the default AsyncEventHandler and HttpProjectConfigManager configurations), the SDK can be easily instantiated with the following OptimizelyFactory method. By default, batch size is 10 and flush interval is 30 seconds.

import com.optimizely.ab.Optimizely;
import com.optimizely.ab.OptimizelyFactory;

public class App {
    public static void main(String[] args) {
        String sdkKey = args[0];
        Optimizely optimizely = OptimizelyFactory.newDefaultInstance(sdkKey);
    }
}

Advanced Example

You can also customize BatchEventProcessor,AsyncEventHandler, and HttpProjectConfigManager using the builder options as shown in the example below:

import com.optimizely.ab.Optimizely;
import com.optimizely.ab.config.HttpProjectConfigManager;
import com.optimizely.ab.event.AsyncEventHandler;
import com.optimizely.ab.event.BatchEventProcessor;
import java.util.concurrent.TimeUnit;

public class App {
    public static void main(String[] args) {
        String sdkKey = args[0];
        
       ProjectConfigManager projectConfigManager = HttpProjectConfigManager.builder()
            .withSdkKey(sdkKey)
            .build();

        EventHandler eventHandler = AsyncEventHandler.builder()
            .withQueueCapacity(20000)
            .withNumWorkers(1)
            .build();

	// Here we are using the builder options to set batch size
        // to 50 events and flush interval to a minute.
        BatchEventProcessor batchProcessor = BatchEventProcessor.builder()
            .withBatchSize(50)
            .withEventHandler(eventHandler)
            .withFlushInterval(TimeUnit.MINUTES.toMillis(1))
            .build();

        Optimizely optimizely = Optimizely.builder()
            .withConfigManager(projectConfigManager)
            .withEventProcessor(batchProcessor)
            .build();
    }
}

❗️

Warning

The maximum payload size is 3.5 MB. Optimizely rejects requests with a 400 response code, Bad Request Error, if the batch payload exceeds this limit.

The size limitation is because of the Optimizely Events API, which Feature Experimentation uses to send data to Optimizely.

The most common cause of a large payload size is a high batch size. If your payloads exceed the size limit, try configuring a smaller batch size.

BatchEventProcessor

BatchEventProcessor is an implementation of EventProcessor where events are batched. The class maintains a single consumer thread that pulls events off of the BlockingCollection and buffers them for either a configured batch size or a maximum duration before the resulting LogEvent is sent to the EventDispatcher and NotificationCenter.

The following properties can be used to customize the BatchEventProcessor configuration using the Builder class.

Builder methods

Use the following methods to customize the BatchEventProcessor.

Advanced configuration

You can set the following properties can be set to override the default configuration for BatchEventProcessor.

For more information, see Initialize the Java SDK.

Side effects

The table lists other Optimizely Feature Experimentation functionality that may be triggered by using this class.

Register a LogEvent listener

To register a LogEvent notification listener:

// There are two ways to register logEvent listener
// 1) Using NotificationCenter.
optimizely.notificationCenter.addNotificationHandler(LogEvent.class, logEventHandler -> {});

// 2) Using addLogEventNotificationHandler method of optimizely.
optimizely.addLogEventNotificationHandler(logEventHandler -> {
});

LogEvent

LogEvent object gets created using EventFactory. It represents the batch of decision and conversion events we send to the Optimizely Feature Experimentation backend.

Close Optimizely Feature Experimentation on application exit

If you enable event batching, you must call the Close method (optimizely.close()) before exiting. This ensures that queued events are flushed as soon as possible to avoid data loss.

❗

Warning

Because the Optimizely Feature Experimentation client maintains a buffer of queued events, you must call close() on the Optimizely Feature Experimentation instance before shutting down your application or whenever dereferencing the instance.