Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert between Message::$expire and DbalMessage::$timeToLive #396

Closed
wants to merge 1 commit into from
Closed

Convert between Message::$expire and DbalMessage::$timeToLive #396

wants to merge 1 commit into from

Conversation

msheakoski
Copy link
Contributor

Fixes a condition which results in the "enqueue" table having a null value for "time_to_live" even though it was set on the Message object prior to sending the event/command. Closes #391

@@ -72,6 +72,7 @@ public function createTransportMessage(Message $message)
$transportMessage->setMessageId($message->getMessageId());
$transportMessage->setTimestamp($message->getTimestamp());
$transportMessage->setDeliveryDelay($message->getDelay());
$transportMessage->setTimeToLive($message->getExpire());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be $message->getExpire() * 1000 as clients message uses seconds where transport uses miliseconds

@@ -97,6 +98,8 @@ public function createClientMessage(PsrMessage $message)
$clientMessage->setContentType($message->getHeader('content_type'));
$clientMessage->setMessageId($message->getMessageId());
$clientMessage->setTimestamp($message->getTimestamp());
$timeToLive = $message->getTimeToLive();
$clientMessage->setExpire((null === $timeToLive) ? null : (int) round($timeToLive));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be (int) round($timeToLive / 1000)

$clientMessage = $driver->createClientMessage($transportMessage);
$this->assertSame(1, $clientMessage->getExpire());

$transportMessage->setTimeToLive(1.5);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI. It is 1.5 milliseconds

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this because the $transportMessage value can be null|int|float, but $clientMessage can only be null|int. Despite $clientMessage claiming to be in seconds, the current behavior of the DbalDriver is to not perform the conversion to milliseconds.

@msheakoski
Copy link
Contributor Author

I was following the same convention used for the delivery delay in order to not break the existing behavior. Although Enqueue\Client\Message specifies that the delay is in seconds:

/**
* Set delay in seconds.
*
* @param int|null $delay
*/
public function setDelay($delay)
{
$this->delay = $delay;
}

when it gets converted into a DbalMessage, it is not converted into milliseconds:
$transportMessage->setDeliveryDelay($message->getDelay());

/**
* Set delay in milliseconds.
*
* @param int $deliveryDelay
*/
public function setDeliveryDelay($deliveryDelay)
{
$this->deliveryDelay = $deliveryDelay;
}

I looked through the fs and redis backends to see if they also have the same behavior, but it does not look like they support delays. How would you like to proceed?

@msheakoski
Copy link
Contributor Author

Just checking if you had any thoughts on this PR and what course of action to take? I think merge it as is for 0.8 to maintain compatibility and change the seconds to milliseconds for 0.9

@makasim
Copy link
Member

makasim commented Mar 27, 2018

The Enqueue Client sets delaying in seconds, where all queue interop transports should use milliseconds. Just make sure you properly convert seconds to milliseconds in the Driver's createClientMessage, createTransportMessage methods.

Fixes a condition which results in the "enqueue" table having a null value for "time_to_live" even though it was set on the Message object prior to sending the event/command.
@msheakoski
Copy link
Contributor Author

Okay, in that case, the current implementation of delivery delay is broken for DBAL. If you look at my previous comment, createTransportMessage currently does not convert from seconds to milliseconds which is the cause of this confusion. I will create a PR to fix this as well, but it will be a BC break for anybody relying on the current behavior where the delay is specified in milliseconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants