Service: Weirdness sending a trigger from Control class inside a service.

jamie commented

2017-06-13 06:58:51 +00:00

(Migrated from git.hazaar.io)

I have a weird situation that is triggered by some shared code using a Warlock\Control object. Basically, this happens:

Service received an event trigger and starts work
Service send status messages OK
Service instantiates another object, in this case, \Application\Model\Request.
Service calls a method on the request that instantiates a \Hazaar\Warlock\Control object.
Request object sends a trigger
Service sends a different trigger

In this case, the trigger sent by the request object using the Control class is sent, but never actioned.

Now for the weirdness. If the service does not send the final trigger, the trigger from the Request object is processed fine.

WHAT.....THE.....F$#@.....??????

I have a weird situation that is triggered by some shared code using a Warlock\Control object. Basically, this happens: * Service received an event trigger and starts work * Service send status messages OK * Service instantiates another object, in this case, ```\Application\Model\Request```. * Service calls a method on the request that instantiates a ```\Hazaar\Warlock\Control``` object. * Request object sends a trigger * Service sends a different trigger In this case, the trigger sent by the request object using the Control class is sent, but never actioned. Now for the weirdness. If the service does not send the final trigger, the trigger from the Request object is processed fine. WHAT.....THE.....F$#@.....??????

jamie commented

2017-06-13 23:15:16 +00:00

(Migrated from git.hazaar.io)

I think this may have something to do with the echo_self parameter in triggers.

Take the following service:

<?php

class TestService extends \Hazaar\Warlock\Service {

    public function init(){

        $this->subscribe('test', 'test');

        $this->subscribe('test_trigger', 'testTrigger');

    }

    public function test(){

        $this->send('OK', '__START__');

        $this->trigger('test_trigger', 'FROM SERVICE');

    }

    public function testTrigger($msg){

        $this->send('OK', '---------------------------> Received: ' . $msg);

    }

}

?>

We will see the ___START___ line in the log output, but the testTrigger() method is never triggered.

I think this may have something to do with the ```echo_self``` parameter in triggers. Take the following service: ```php <?php class TestService extends \Hazaar\Warlock\Service { public function init(){ $this->subscribe('test', 'test'); $this->subscribe('test_trigger', 'testTrigger'); } public function test(){ $this->send('OK', '__START__'); $this->trigger('test_trigger', 'FROM SERVICE'); } public function testTrigger($msg){ $this->send('OK', '---------------------------> Received: ' . $msg); } } ?> ``` We will see the ```___START___``` line in the log output, but the ```testTrigger()``` method is never triggered.

jamie commented

2017-06-13 23:46:09 +00:00

(Migrated from git.hazaar.io)

Hmmm... Could be a command sequence issue. When sending a trigger, the sender expects an OK response to let it know the world is a happy place. However when sending a trigger we are processing the even queue as soon as possible, which as it turns out, is BEFORE we send the OK. So, if the command is being echoed, we send the EVENT packet before we send the OK, then after the queue is processed we send the OK. So because the sender is expecting an OK, when it receives the EVENT it takes that as "not OK", doesn't process it as an EVENT and handles it as a failed trigger. Makes sense!

So, I have moved the queue processing call to AFTER the OK is sent and the above test trigger is working. Now we will test again in our live environment to see if this was the issue.

Hmmm... Could be a command sequence issue. When sending a trigger, the sender expects an OK response to let it know the world is a happy place. However when sending a trigger we are processing the even queue as soon as possible, which as it turns out, is BEFORE we send the OK. So, if the command is being echoed, we send the EVENT packet before we send the OK, then after the queue is processed we send the OK. So because the sender is expecting an OK, when it receives the EVENT it takes that as "not OK", doesn't process it as an EVENT and handles it as a failed trigger. Makes sense! So, I have moved the queue processing call to AFTER the OK is sent and the above test trigger is working. Now we will test again in our live environment to see if this was the issue.

jamie commented

2017-06-14 00:10:17 +00:00

(Migrated from git.hazaar.io)

mentioned in commit e33ff40791

mentioned in commit e33ff4079138a009ac0cf1af0352f6e753bb0d5d

jamie commented

2017-06-14 00:23:07 +00:00

(Migrated from git.hazaar.io)

mentioned in commit 34e5b8bc0f

mentioned in commit 34e5b8bc0fdaada595714cf5a30cd97d3534e209

jamie commented

2017-06-14 00:52:55 +00:00

(Migrated from git.hazaar.io)

I think I have figured it out!!!! This is all happening because there is an EVENT packet sitting in the receive buffer BEFORE we try and send a TRIGGER. So once the TRIGGER is sent, the first thing we get is EVENT which is handled as a "not OK" response.

Things to try:

Clean out (ie: process) the receive buffer right before sending something.
Last resort: Ditch the concept of an OK response as it seems to be mucking stuff up without providing any real value. It's not like we retry failed sends or anything.
If we REALLY want an OK response, maybe have a send queue, with IDs, that gets processed until an OK is received with the right ID. That would be quite cool, if a lot a work.

I think I have figured it out!!!! This is all happening because there is an EVENT packet sitting in the receive buffer BEFORE we try and send a TRIGGER. So once the TRIGGER is sent, the first thing we get is EVENT which is handled as a "not OK" response. Things to try: * Clean out (ie: process) the receive buffer right before sending something. * Last resort: Ditch the concept of an OK response as it seems to be mucking stuff up without providing any real value. It's not like we retry failed sends or anything. * If we REALLY want an OK response, maybe have a send queue, with IDs, that gets processed until an OK is received with the right ID. That would be quite cool, if a lot a work.

jamie commented

2017-06-14 01:04:13 +00:00

(Migrated from git.hazaar.io)

I have gone with option 2, ditch the OK. Turns out that SYNC and TRIGGER are the only transmissions that waited for an OK. SYNC still requires it as it is what initiates the client connection and sends the client ID. Everything else can just send blindly. If we are still losing things and want send retries, we can later implement a packet out-queue with send IDs and require responses.

jamie commented

2017-06-14 01:08:36 +00:00

(Migrated from git.hazaar.io)

closed via commit 14044cf012

closed via commit 14044cf0126251ea6f21714710dbbdf516964b85

Rows
Columns

Service: Weirdness sending a trigger from Control class inside a service. #18