Emitters

The Tracker instance must be initialized with an emitter. This section will go into more depth about the Emitter and how it works under the hood.

Emitter emitter("com.acme", Emitter::Method::POST, Emitter::Protocol::HTTP, 52000, 52000, 500, "sp.db");
Code language: CSS (css)

There are other optional arguments:

Argument Name	Description	Required?
`uri`	The URI to send events to	Yes
`method`	The request type to use (GET or POST)	Yes
`protocol`	The protocol to use (http or https)	Yes
`send_limit`	The maximum amount of events to send at a time	Yes
`byte_limit_post`	The byte limit when sending a POST request	Yes
`byte_limit_get`	The byte limit when sending a GET request	Yes
`db_name`	Defines the path and file name of the database	Yes

The db_name can be any valid path on your host file system (that can be created with the current user). By default it will create the required files wherever the application is being run from.

5.1 Under the hood

Once the emitter receives an event from the Tracker a few things start to happen:

The event is added to a local Sqlite3 database (blocking execution)
A long running daemon thread is started which will continue to send events as long as they can be found in the database (asynchronous)
The emitter loop will grab a range of events from the database up until the SendLimit as noted _above
The emitter will send all of these events as determined by the Request, Protocol and ByteLimits
- Each request is sent in its thread.
Once sent it will process the results of all the requests sent and will remove all successfully sent events from the database

If you’d like to learn more about Snowplow Insights you can book a demo with our team, or if you’d prefer, you can try Snowplow technology for yourself quickly and easily.

Guest

Collecting data with Trackers and Webhooks

Emitters

5.1 Under the hood

Guest

Collecting data with Trackers and Webhooks

5.1 Under the hood

Related content you may find interesting