NetworkVmsExampleBagOfTasksApp and NetworkVmsExampleSimpleApp are freezing

[manoelcampos]

NetworkVmsExampleBagOfTasksApp and NetworkVmsExampleSimpleApp examples are freezing.

Expected behavior

The examples should execute and show the results table.

Actual behavior

The examples keep in an infinite loop.

Specifications like the version of the project, operating system or workload file used

Current development version.

[AbderrahmanL]

Hello
Is there any clue about the problem here? I did some debugging and it seems that even if the event queue has no elements, the future.isEmpty() still returns false !?
Edit: I'm speaking about the eventLoop in the CloudSim class
Update: using a Cloudlet instead of Network Cloudlet makes the examples run fine
Update: Commenting the part in createNetworkCloudlets() that adds tasks make the example terminate without infinite loop but the cloudlets won't finish execution

[manoelcampos]

I started to work on this feature a long time ago but I stopped. Yeah, the issue is with the NetworkCloudlet and the CloudletTasks. Probably a CloudletSendTask is sending messages that a CloudletReceiveTask is not receiving.

I'll try to follow your tips and let you know if I find the source of the issue. The PacketSchedulerSimple class is the one accountable to process network packets. It's used inside the CloudletSchedulerAbstract.updateCloudletProcessingAndPacketsDispatch method.

[AbderrahmanL]

Okey ill try and see from my side too.

[manoelcampos]

If you change the NetworkVmsExampleSimpleApp.NUMBER_OF_NETCLOUDLET_EXECUTION_TASKS to 1, it works. So the issue is when there is more than 1 CloudletExecutionTask for the same NetworkCloudlet. Now I need to check how to fix it.

[manoelcampos]

It's working for the NetworkVmsExampleSimpleApp, but not for the NetworkVmsExampleBagOfTasksApp yet.

[AbderrahmanL]

Please can can you tell me what was the problem ? I read the code in your commit but i didn't get what change exactly fixed it Thank you!

…

On Tue, Jun 26, 2018 at 8:55 PM, Manoel Campos da Silva Filho < ***@***.***> wrote: It's working for the NetworkVmsExampleSimpleApp, but not for the NetworkVmsExampleBagOfTasksApp yet. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AefY3ZIpnpoM0IOa9nEwkSnbIXev57pQks5uAoO_gaJpZM4NcOPJ> .

[manoelcampos]

Sorry, I made a lot of changes not related to the issue (most of them just refactoring). This is a bad practice 😢, but since I'm always in a rush, I don't have time to go back and make such changes afterward (and usually I will not remember where I need to refactor). As I was almost always working alone, it was never a problem. I'll try to do it right next time.

Basically, the issue was caused because the number of executed MIPS of each CloudletExecutionTask was not being updated correctly for the second task, this way that task never finished. I included some comments in the commit at fc82201.

[AbderrahmanL]

Thank you! Don't worry ill tell you whenever i don't get something.

[manoelcampos]

Just closed the issue, this time reducing the number of changes.
The issue was just with the NetworkVmsExampleBagOfTasksApp.
Check comments at 270bac2

[AbderrahmanL]

Hello I have found something a bit odd: receivePackets in the PacketSchedulerSimple assumes that the current cloudlet is the destination cloudlet without verifying so. As a result if we have cloudlets A in a host X that is sending a msg to cloudlet B in another host Y, and B doesn't have receive task, but a cloudlet C in host Y does have the receive task, C will receive the messages instead. First I recommend that the parameter of receivePackets should not be named "sourceCloudlet" it should be something like "candidateReceiverCloudlet" or something that means the same since this is what it is actually. The getSourceVm method in the Task class should be just getContainingVm since "source" is especially deceiving in this whole messaging context (in getPacketsSentToGivenTask for example). So before logging to DEGUB that this candidate has received the cloudlet it should be verified that the id of this "candidateReceiverCloudlet" is actually the destination cloudlet's id, this can be done in the getPacketsSentToGivenTask, by comparing ids of cloudlets in addition to Vms's.

[manoelcampos]

I'll need a couple of days to take a look at this issue because I'm working with issue #24 for my thesis experiments.

Thanks for reporting.

[AbderrahmanL]

Okey good luck with your thesis!

…

On Thu, Jun 28, 2018 at 2:03 PM, Manoel Campos da Silva Filho < ***@***.***> wrote: I'll need a couple of days to take a look at this issue because I'm working with issue #24 <#24> for my thesis experiments. Thanks for reporting. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AefY3enIKWBjSkCrg65KCV3jSTTsinmZks5uBMYogaJpZM4NcOPJ> .

[manoelcampos]

I have found something a bit odd: receivePackets in the
PacketSchedulerSimple assumes that the current cloudlet is the destination
cloudlet without verifying so. As a result if we have cloudlets A in a host
X that is sending a msg to cloudlet B in another host Y, and B doesn't have
receive task, but a cloudlet C in host Y does have the receive task,
C will receive the messages instead.

I've created this example with the scenario you described and verified that the issue doesn't happen in fact. The receivePackets() method just checks if there are packets to be received from the current cloudlet. The method will be called for every running cloudlet that has a receive task. It then just checks if there are packets previously sent from any other Cloudlets that are targeting the current Cloudlet. In such a case, it delivers the packets to the current Cloudlet.

The provided example just keeps in an infinite loop, since Cloudlet 2 will keep waiting for packets that aren't sent to it. This, in fact, is a different issue. There should be a timeout to avoid this infinite loops. I'll open a new issue.

First I recommend that the parameter of receivePackets should not be named
"sourceCloudlet" it should be something like "candidateReceiverCloudlet" or
something that means the same since this is what it is actually

Fixed.

The getSourceVm method in the Task class should be just getContainingVm
since "source" is especially deceiving in this whole messaging context (in
getPacketsSentToGivenTask for example).

I reviewed the code and maybe the documentation and method names are causing confusion.
The getPacketsSentToGivenTask() method will just check if packets targeting a Cloudlet were already received. Then it returns those packets to be delivered for that Cloudlet. Otherwise, it just returns an empty list. I just renamed the method to getPacketsSentToCloudlet tried to make the documentation clearer. If that method returns some packets, the receivePackets method just delivers them to the cloudlet. This way, the vm inside the receive task is in fact the one from which packets are expected to be received from (the packets' source VM).

So before logging to DEGUB that this candidate has received the cloudlet it
should be verified that the id of this "candidateReceiverCloudlet" is
actually the destination cloudlet's id, this can be done in the
getPacketsSentToGivenTask, by comparing ids of cloudlets in addition to
Vms's.

You're right. I just included a new filter in the getPacketsSentToCloudlet method (previously getPacketsSentToCloudlet). You can check this example that creates the 3 usual NetworkCloudlets and makes Cloudlet 0 to send packets to the other ones. I used different packet sizes for each destination Cloudlet to make sure they are receiving the correct packet.

Check commit 5a4592b for details.

[AbderrahmanL]

What i said is a result i knew that the method will be called for every cloudlet still what i discribed is the result, even if the method will be called for the cloudlet B and B is the destination cloudlet, C will receive the packets in the end since it has a receiver task and B has none. I will recheck and next time ill try to be more clear with my explanation.

…

--Thanks

On Sat, Jun 30, 2018 at 1:24 AM, Manoel Campos da Silva Filho < ***@***.***> wrote: I have found something a bit odd: receivePackets in the PacketSchedulerSimple assumes that the current cloudlet is the destination cloudlet without verifying so. As a result if we have cloudlets A in a host X that is sending a msg to cloudlet B in another host Y, and B doesn't have receive task, but a cloudlet C in host Y does have the receive task, C will receive the messages instead. I've created this example with the scenario you described <https://gist.github.com/manoelcampos/ceff3327ce257145c8ee988fad380963> and verified that the issue doesn't happen in fact. The receivePackets() method just checks if there are packets to be received from the current cloudlet. The method will be called for every running cloudlet that has a receive task. It then just checks if there are packets previously sent from any other Cloudlets that are targeting the current Cloudlet. In such a case, it delivers the packets to the current Cloudlet. The provided example just keeps in an infinite loop, since Cloudlet 2 will keep waiting for packets that aren't sent to it. This, in fact, is a different issue. There should be a timeout to avoid this infinite loops. I'll open a new issue. First I recommend that the parameter of receivePackets should not be named "sourceCloudlet" it should be something like "candidateReceiverCloudlet" or something that means the same since this is what it is actually Fixed. The getSourceVm method in the Task class should be just getContainingVm since "source" is especially deceiving in this whole messaging context (in getPacketsSentToGivenTask for example). I reviewed the code and maybe the documentation and method names are causing confusion. The getPacketsSentToGivenTask() method will just check if packets targeting a Cloudlet were already received. Then it returns those packets to be delivered for that Cloudlet. Otherwise, it just returns an empty list. I just renamed the method to getPacketsSentToCloudlet tried to make the documentation clearer. If that method returns some packets, the receivePackets method just delivers them to the cloudlet. This way, the vm inside the receive task is in fact the one from which packets are expected to be received from (the packets' source VM). So before logging to DEGUB that this candidate has received the cloudlet it should be verified that the id of this "candidateReceiverCloudlet" is actually the destination cloudlet's id, this can be done in the getPacketsSentToGivenTask, by comparing ids of cloudlets in addition to Vms's. You're right. I just included a new filter in the getPacketsSentToCloudlet method (previously getPacketsSentToCloudlet). You can check this example <https://gist.github.com/manoelcampos/5584a7b36d2e401c9265bf7927177cfb> that creates the 3 usual NetworkCloudlets and makes Cloudlet 0 to send packets to the other ones. I used different packet sizes for each destination Cloudlet to make sure they are receiving the correct packet. Check commit 5a4592b <5a4592b> for details. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AefY3VF9dS2-3XZBn3sHTMc2U1V3CFymks5uBrcmgaJpZM4NcOPJ> .

[manoelcampos]

I didn't get what you mean this time.
Even if Cloudlet B doesn't have a receiver task and Cloudlet C does, the method getPacketsSentToCloudlet makes sure that just packets targeting the correct Cloudlet are delivered (after the change you proposed).

If you check the example of the first link, it keeps in an infinite loop because Cloudlet C just keeps waiting for packets that aren't sent. Packets sent to Cloudlet B are received by the Host (as you can see in the log). However, since the Cloudlet B doesn't have a receive task, the packets are not delivered.

This way, if there is an issue, it's not clear to me what it is.