Device SDK AutoEvents Behavior

[teenccu]

Hello All,

I ask this question to understand the expected behavior of device SDK for the auto event intervals.

The Auto events of the each resources are fired in the this particular code of executer.go

func (e *Executor) Run(ctx context.Context, wg *sync.WaitGroup, buffer chan bool, dic *di.Container) {
wg.Add(1)
defer wg.Done()
lc := bootstrapContainer.LoggingClientFrom(dic.Get)
for {
select {
case <-ctx.Done():
return
case <-time.After(e.duration):
if e.stop {
return
}
lc.Debugf("AutoEvent - reading %s", e.sourceName)
evt, err := readResource(e, dic)
if err != nil {
.......
}

Now if a autoevent for a resource is configured for 2 secs then according to the code "case <-time.After(e.duration)" there will be wait of 2 seconds after every cycle of data read. That means if we assume readResource(e, dic) is taking 5 seconds, then the next auto event will be fired after 7 seconds.

Now when a user is configuring an auto event with 2 seconds , he might expect that his auto event should get fired in every 2 seconds and the database contain the count of events close to that interval considering some delay according to read the resource. This is not the case in the implementation as the interval of auto-event is added with the time of retreiving the data. If for some reason the readResource() is taking considerable amount of more time compare to the autoevent interval user may think it as loss of data in a particular time frame. The alternative expectation of user can be auto events should be fired in the given intervals and should be queued and readresource() should process them seperately may be in a seperate go routine.

So my question is if the above understanding is correct or user need to accept that auto-events are fired in a interval after a read cylcle is completed.

Thanks in advance for the clarification.

[cloudxxx8]

Yes, it is the current behavior, and we can improve it by wrapping the execution (read + send event) as an asynchornous function to resolve this issue.

[teenccu]

@cloudxxx8 thanks a lot for your response.

If you dont mind I would like to clarify a bit more.

When you say wrapping (read + send event) as an asynchornous function do you mean all asynchronous functions are executing in parallel or those are queued and fired sequentially ? I was wondering if executed in parallel it might result certain number of read + send event executing parallel and making connection to device in probably same time resulting almost same timestamp in the events. It can happen when it takes considerable amount of time to process (read + send event) and less time interval of auto event.

Thanks in advance again for your answers.

[cloudxxx8]

asynchronous functions means the (read + send event) consuming time won't be included to the auto event interval, and the execution from different autoevents have run concurrently in the current implementation.
The device connection issue should be handled by the device service driver itself. For example, MQTT Device Service use the same connection in the driver, and the Modbus Device Service reference implementation uses lock to manage the concurrent requests.

[teenccu]

Thank you @cloudxxx8

[cloudxxx8]

enhancement issue is opened here: edgexfoundry/device-sdk-go#1627