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

NetworkVmsExampleBagOfTasksApp and NetworkVmsExampleSimpleApp are freezing #85

Closed
manoelcampos opened this Issue May 16, 2017 · 15 comments

Comments

Projects
None yet
2 participants
@manoelcampos
Copy link
Owner

manoelcampos commented May 16, 2017

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.

@manoelcampos manoelcampos added the bug label May 16, 2017

@manoelcampos manoelcampos self-assigned this May 16, 2017

@AbderrahmanL

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 25, 2018

Okey ill try and see from my side too.

@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 26, 2018

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

@AbderrahmanL

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 26, 2018

@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 27, 2018

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

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 27, 2018

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

@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 27, 2018

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

manoelcampos added a commit that referenced this issue Jun 27, 2018

Updates version number after fixing Network Module (Issue #85)
Signed-off-by: Manoel Campos <manoelcampos@gmail.com>
@AbderrahmanL

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 28, 2018

@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 28, 2018

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

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 28, 2018

@manoelcampos manoelcampos added this to the CloudSim Plus 3.0 milestone Jun 28, 2018

Repository owner deleted a comment from AbderrahmanL Jun 29, 2018

manoelcampos added a commit that referenced this issue Jun 29, 2018

Updates #85
Signed-off-by: Manoel Campos <manoelcampos@gmail.com>
@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 29, 2018

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

This comment has been minimized.

Copy link
Contributor

AbderrahmanL commented Jun 30, 2018

@manoelcampos

This comment has been minimized.

Copy link
Owner Author

manoelcampos commented Jun 30, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.