You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using stomp-php with Drupal through the Islandora stack and have hit an issue.
When an attempt to send a message fails, it leaves the StatefulStomp client with an isConnecting state of true.
So if a second message is attempted using the same client we hit
Call to a member function getBeginFrame() on null in Stomp\States\ProducerTransactionState->initTransaction() (line 53 of vendor/stomp-php/stomp-php/src/States/TransactionsTrait.php).
This seems to be because the transaction trait chains getProtocol even though it could be null.
I'd suggest removing the check of isConnecting from the getProtocol function and only rely on isConnected before returning the protocol.
i.e.
public function getProtocol()
{
if (!$this->isConnected()) {
$this->connect();
}
return $this->protocol;
}
But if there is a good reason for leaving isConnecting in there, then perhaps some method to reset the isConnecting state (as it is a private variable)?
The text was updated successfully, but these errors were encountered:
We are using stomp-php with Drupal through the Islandora stack and have hit an issue.
When an attempt to send a message fails, it leaves the StatefulStomp client with an
isConnecting
state oftrue
.So if a second message is attempted using the same client we hit
This seems to be because the transaction trait chains
getProtocol
even though it could benull
.I'd suggest removing the check of
isConnecting
from thegetProtocol
function and only rely onisConnected
before returning the protocol.i.e.
But if there is a good reason for leaving
isConnecting
in there, then perhaps some method to reset theisConnecting
state (as it is a private variable)?The text was updated successfully, but these errors were encountered: