why event broadcast is queued ?

Remove the implementation of ShouldQueue of your event listener.

I don't have any event listener insted my event class itself broadcasts the message.

Show your code.

Queuing the broadcasting is a nonsense, the event processing itself is either queued or not.

This is my event class:

` namespace App\Events;

use App\Events\Event; use Illuminate\Queue\SerializesModels; use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class NotifyQuoteUpdates extends Event implements ShouldBroadcast { use SerializesModels;

public $dataQuote;

/**
 * Create a new event instance.
 *
 * @return void
 */
public function __construct($quote)
{
    $this->dataQuote = $this->assignAttributes($quote);
}

public function assignAttributes($quote)
{
    $dataObj = new \stdClass();
    $dataObj->quote = $quote;
    $dataObj->owner = $quote->owner->showGlobally();
    return $dataObj;
}

/**
 * Get the channels the event should be broadcast on.
 *
 * @return array
 */
public function broadcastOn()
{
    return [
        $this->dataQuote->quote->task->fetchAlertPrefix()
    ];
}

} `

I am calling this by event(new NotifyQuoteUpdates ($quote) );

From the doc :

Before broadcasting events, you will also need to configure and run a queue listener. All event broadcasting is done via queued jobs so that the response time of your application is not seriously affected.

All event broadcasting are queued. Sorry I forgot this in my last posts. So there is no way to not use queue when broadcasting, why do you even care?

Actually i want the user to update in realtime for the status of their request, so as i disclose their request it should not be queued insted it should broadcast there and then only. I am using the socket.io and redis for that. How can it be possible to not queue event broadcast when using queue driver database ?

Is this possible that every job to be executed as it is received, not the sync driver so there is no delay in user result. ?

Sorry but I dont understand. If you want to get the user informed of the progression of a long process you should fire many events as different steps of the processing so those events get broadcasted and you can update his UI.

Not sure if this solution works, but I dont understand what you want to do.

The problem is that i want the event to be broadcast in realtime, means i have two users chatting and at the same time if a user updates his request then it should immediately broadcast to other users means it should no be queued, the problem if i have many jobs queued in and then if this job is processed after the completion of other jobs it is then not realtime. I hope you got my point ?

I guess I understood. You just have to put many queue running, one dedicated to the chat and the other to the long processing job.

// In chat events
public function onQueue()
{
    return 'chat';
}

// In long processing events
public function onQueue()
{
    return 'long-processing';
}

then

$ php artisan queue:listen chat
$ php artisan queue:listen long-processing

Thanks pmall, but i am recieving an error [InvalidArgumentException] No connector for []

Looking at the configurations in the app\config\queues.php i have the following parameters for the database. 'database' => [ 'driver' => 'database', 'table' => 'jobs', 'queue' => 'default', 'expire' => 60, ], How to setup multiple queues ?

@dhiman252 @pmall - The first argument to the queue:listen command is the driver that is being used, in your case, 'database'. Your queue:listen command should look like the following:

$ php artisan queue:listen database --queue="chat"
$ php artisan queue:listen database --queue="long-processing"

Hope that helps!

You need to implements ShouldBroadcastNow. It means that laravel use "sync" driver.

https://laravel.com/api/5.1/Illuminate/Contracts/Broadcasting/ShouldBroadcastNow.html

Queued broadcasts actually make your app more responsive and allows a quicker "realtime" experience. That's why this is the default behavior of broadcasting. You trigger the backend action, then you can immediately respond to your user instead of having to wait on the process to complete.