Multicast to 10 PC creates two upd-sender processes

[brizio]

Hi all,
just a question: i created a group with 10 pc and I created a multitask deploy job for that group.
Fog created two different row in the multicastSessions table one with 7 msClients and one with 3 msClients.
This is slowing down the whole deploy process (more network traffic, server I/O contention because of the two udp-sender processes).
Is this behaviour normal? I supposed to have just one multicastSessions with 10 clients.

I’m using fog svn 3559 on Centos 6.6.

[Tom Elliott]

I guess we need details.

Are all systems in the group set with the same image id?

[brizio]

Hi Tom,
thank you for the quick reply.
Yes, all the 10 PC in the same group are set with the same Image Id (ID: 9).
I can see the same ID also in the multicastSessions table, column msImage.

[brizio]

It seems also that the upd-sender process started with
min receivers=5 for the first session (the one set with msClients=7)
min receivers=3 for the second session (the one set with msClients=3)

that means that 2 PC were not depoloyed: in fact they are still waiting on the first PartClone screen.

[Tom Elliott]

@brizio Can you clear the multicastSessions, multicastSessionsAssoc, and tasks tables?

The tasks I only want you to clear the multicast jobs.

A mysql statement to do these things would be:

TRUNCATE TABLE multicastSessions;
TRUNCATE TABLE multicastSessionsAssoc;
DELETE FROM tasks WHERE taskTypeID=8;

My guess, from an earlier revision, a multicast session didn’t clear properly. Because of the non-clearing, a few hosts linked to the wrong Job and the others, who had no prior setting stored in the DB, created their own session.

Again, this is just a guess, as I really don’t know what actually caused this to happen.

[brizio]

Right, i’ll clean the DB then. Thank you.

[Wayne Workman]

@Tom-Elliott said:

@brizio Can you clear the multicastSessions, multicastSessionsAssoc, and tasks tables?

The tasks I only want you to clear the multicast jobs.

A mysql statement to do these things would be:

TRUNCATE TABLE multicastSessions;
TRUNCATE TABLE multicastSessionsAssoc;
DELETE FROM tasks WHERE taskTypeID=8;

My guess, from an earlier revision, a multicast session didn’t clear properly. Because of the non-clearing, a few hosts linked to the wrong Job and the others, who had no prior setting stored in the DB, created their own session.

Again, this is just a guess, as I really don’t know what actually caused this to happen.

I’m working on a “Troubleshoot Multicast” article that has commands more friendly to Red-Hat based distros… aparently the truncate commands don’t work in Fedora 22… so… Here you go:

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_Downloading_-_Multicast