virtual wuclass will not work if it is deployed more than one time

[curtis1213]

Virtual wuclass works after first time deployment. Once it is deployed, the mapper considers wudevice has the virtual wuobject and won't order VM to create a new one. In this situation, the virtual wuclass will fail because the virtual wuobject is deleted and no longer exist in wudevice after it is deployed once again.

[pencilcheck]

This is not a small issue to fix, as it requires a drastic change in the wuclass/wuobject models in master.

Under the current model, the workaround would be to let mapper to create a new virtual object for every found virtual java wuobjects on the nodes, but this is not ideal since we will be creating a lot of waste wuobjects after each deploy. One way to fix that would have to write a routine to clean up those unused virtual java wuobjects after each map.

But this fix would not be scalable nor easy to maintain and definitely confusing as hell. So I would like to avoid this workaround.

I believe this issue brings up an important aspect of partial deployment in the progression framework, and that's one reason I don't want to take this issue lightly.

[wycc]

This can be solved by a simple change in the VM. In the getWuObjectList, we need to set a flag to tell the master this wuobject is virtual. Then, the codegen will do the right job for it. In the future, we can skip those wuobjects in the full deployment.

This is a small change in the wkpf_comm_handle_message. We need to check the WKPF_IS_VIRTUAL_WUOBJECT and then return it to the master. In the parser of the master, we can mark the wuobject as virtual correctly and then the codegen will generate the right code for it.

2013/9/13 Penn Su notifications@github.com

This is not a small issue to fix, as it requires a drastic change in the wuclass/wuobject models in master.

Under the current model, the workaround would be to let mapper to create a new virtual object for every found virtual java wuobjects on the nodes, but this is not ideal since we will be creating a lot of waste wuobjects after each deploy. One way to fix that would have to write a routine to clean up those unused virtual java wuobjects after each map.

But this fix would not be scalable nor easy to maintain and definitely confusing as hell. So I would like to avoid this workaround.

I believe this issue brings up an important aspect of partial deployment in the progression framework, and that's one reason I don't want to take this issue lightly.

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/46#issuecomment-24401632 .

YC

Phone: 886-2-23516989 Mobile: 0919816155

[wycc]

This is something must be fixed in this release.

2013/9/14 Yu-Chung Wang wycc@homescenario.com

This can be solved by a simple change in the VM. In the getWuObjectList, we need to set a flag to tell the master this wuobject is virtual. Then, the codegen will do the right job for it. In the future, we can skip those wuobjects in the full deployment.

This is a small change in the wkpf_comm_handle_message. We need to check the WKPF_IS_VIRTUAL_WUOBJECT and then return it to the master. In the parser of the master, we can mark the wuobject as virtual correctly and then the codegen will generate the right code for it.

2013/9/13 Penn Su notifications@github.com

This is not a small issue to fix, as it requires a drastic change in the wuclass/wuobject models in master.

Under the current model, the workaround would be to let mapper to create a new virtual object for every found virtual java wuobjects on the nodes, but this is not ideal since we will be creating a lot of waste wuobjects after each deploy. One way to fix that would have to write a routine to clean up those unused virtual java wuobjects after each map.

But this fix would not be scalable nor easy to maintain and definitely confusing as hell. So I would like to avoid this workaround.

I believe this issue brings up an important aspect of partial deployment in the progression framework, and that's one reason I don't want to take this issue lightly.

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/46#issuecomment-24401632 .

YC

Phone: 886-2-23516989 Mobile: 0919816155

YC

Phone: 886-2-23516989 Mobile: 0919816155

[pencilcheck]

We already did that. WuObjects have a virtual flag for that. The problem is not that codegen will take care of it, it is not as stated in my previous response.

[pencilcheck]

Ok, just wrrite up a fix in the local copy, ready to push. Basically I was wrong, it doesn't matter if we create a new wuobject in mapper or not, they will not be saved to db. The only missing link is in the wkpf_comm handler where VM constructs the response for a list of wuobjects on the node where it doesn't give the master information on its virtuality, so I added that, but that bumps the message size up to 39 bytes (max 40 bytes according to wkcomm.h), barely over the limit.

If nothing goes wrong, this commit would be able to solve the problem in this issue because the mapper will take existing virtual wuobject and will generate the appropriate code to create the virtual wuobject on the node in the application2.java.

[pencilcheck]

Tested with locally and there appears to be working, will close this issue.