Free Support Forum - aspose.com

MPP Does not recaclculate

#21

also note if you try to recalculate the first task in this mpp, the summary taks it will also loop (run out of stack space error).


the effect of these bugs is to use all the memory on the server and IIS has to be reset.

you MUST consider how to prevent the loopng in general even if you dont fix the problems as it effectively crashes the application.
#22

Hi Richard,


The issue of stack overflow with recalculation of Task 1 has been logged as TASKS-33381 in our issue tracking system.

However, I was not able to reproduce the issue of hanging even after Task 5 was activated. Is there anything else I need to consider for reproducing the issue?

Regarding the work around with respect to point (2), I have talked to our development team and this issue needs to be investigated in details for a fix. We’ll try to provide you with a quick fix version as soon as we reach to a solution for this problem. Please spare us a little time in this regard.
#23

Hi Richard,


We have analyzed the issue related to the logged ticket TASKS-33379 and found that the tasks were scheduled based on ASAP scheduling policy. That was the reason why MS Project and Aspose.Tasks shifted dates back due to lack of any constraints attached to this task.

In order to achieve your objective, please apply the MustStartOn constraint to the desired task and the dates will be arranged as expected.

Sample Code:

Task task = project.GetTaskById(15);<o:p></o:p>

task.Start = task.Start.AddDays(1);

task.ConstraintType = ConstraintType.MustStartOn;

task.ConstraintDate = task.Start;

Task.Recalculate(project.RootTask);

#24

Thi is not correct and the workaround is not useful.


I am asking two things:

1. That under NO circumstances should I have to reset a server because aspose tasks has run it out of memory. The MPP provided does this on the orphan task and on the first task. I don’t know why you cant replicate it on the orphan task, but it is a general requirement, you must not allow it to happen under any circumstance. This should be an urgent fix. I avoid any “orphan task” by detecting it, making it inactive and so ignoring it. I avoid the first task by making sure not to recalculate it (eg see code below). I also plug in its dates of the projects last end date after the recalculate to avoid its recalculation.

2. The tasks recalculaate should do exactly what the MPP does. It does NOT. There is a finish to start constraint that is not being honored correctly in ASPOSE tasks. Attached is the recalculated MPP in MS Project 2013 and the constraints on task 15 are honored. In Aspose they are NOT. See the attached picture, where the end dat is correct, wheras aspose “shrinks” the total duration. I fix up the first date separately by lugging in the last finish date to also be eg 15/8/2013


A work around that depends on knowing which task to recalculate to get over this is no workaround at all. Of course I need a general solution not one specific to an MPP. Currently I have 8 different MPP’s from the customer and eventually expect around 20. BTW son are much more complicated with more than 100 taks and they seem to work. To date only this one demonstrates the two issues.


Now fortnately I did manage to work around both issues as follows before I met the customer today:

’ Replace this offending code that is based on recalculating the second task on
‘with new code
’ Aspose.Tasks.Task.Recalculate(tsk)
’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’
prj.CalculateCriticalPath()
Dim k As Integer = 0
For Each tsk1 As Aspose.Tasks.Task In collector.Tasks
If tsk1.IsCritical And tsk1.IsActive And tsk1.IsMilestone Then
k = k + 1
’ Avoid killing the customer server, and recalculate all taks on the critical path
’ forcing the longest paths to be honored correctly
If k > 1 Then Aspose.Tasks.Task.Recalculate(tsk1)
End If
Next
’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’'
ie replacing the ’ Aspose.Tasks.Task.Recalculate(tsk) with a calculation based on critical path and forcing the finsih to start constraint on task 15 to honor the longest duration, or indeed any finish to start.

I am using MPP 2013 and my customer MPP 2010 so it is not version dependent.


#25

Hi Richard,


We are analyzing the issue continuously and following are our findings:

Regarding the exception on task 1 calculation, development team is working and that will be resolved soon.

Bad.mpp file is opened in MSP 2013 and one day is added to task 15 (j). It is observed that a constraint “Start No Earlier Than” is automatically added by MSP. It can be seen in the first column titled “Indicator”.

Aspose.Tasks also requires that constraint must be added to the task where days are added. Its required because the default is ASAP as mentioned earlier.

Also please use Task.Recalculate function for root task always as it shifts all the dates of the successor tasks.

Please review the following code which performs this task successfully.

string newProject = “BAD.mpp”;
Project project = new Project(newProject);
Task t = project.GetTaskById(15);
DateTime oldStart = t.Start;
t.Start = oldStart.AddDays(1);
t.ConstraintDate = t.Start;
t.ConstraintType = ConstraintType.StartNoEarlierThan; //Similar to MSP
Task.Recalculate(project.RootTask);
project.Save(“recalc.mpp”, SaveFileFormat.MPP);

#26

Hi,


Thank you for your effort. The problem is that I need a general solution, not one that encodes specific tasks such as task 15. We have no idea what the customer will provide.

Regards

Richard
#27

Further …


QUOTE
It is observed that a constraint “Start No Earlier Than” is automatically added by MSP.
UNQUOTE

Exactly … and the customer expects aspose to behave in the same way. They will do that by comparing agains MSP. Also logically for this particular MPP what aspose does makes no sense in the real world. We are dealing with “real world” project managers here who also know MSP well and will use it as there reference when they get an “unreal” result.
#28

And more …


QUOTE
Also please use Task.Recalculate function for root task always as it shifts all the dates of the successor tasks.
UNQUOTE

This is NOT the whole requirement. The project mangers may choose to reschedule a task that is not at the beginning of the project. I am just giving you a simple example. Again, they expect the recalculation to match MSP.

BTW we have an example with 137 tasks that seems to work perfectly.

Please also note however, I very much appreciate you efforts and clarifications.

Regards

Richard
#29

Hi Richard,


Updating task 15 was just an example as you took it as a use case in this discussion. The same is applicable to any other task as well.

Regarding the automatic creation of constraints, this can be investigated further for implementation but may have impact on others. Moreover, if you are manipulating a task’s start date in MSP manually, it is as equivalent to handling a MSP manually and Aspose.Tasks provides the same behavior for MSP in manual mode. That’s why adding a constraint makes overall project’s calculations more clear. Do you want this to be automatically done when Start date of a task is changed? Please note that it may take considerable amount of time to investigate the implementation of this enhancement.

Regarding your example file of 137 tasks, I would request you to please provide us your sample file with your code sample so that we can investigate the issue by comparing it with this one and provide you further assistance.

Please also note that Task.Calculate(RootTask) does not take into consideration the first/root task only. Infact, it takes all the tasks in the project tree for recalculation when we apply recalculate statement on the root task.
#30

Hi,


Actually im changing end dates ot start dates.

A general solution based on the code provided is quite hard to work out, I would have to detect when the situation occurs.

The requirement is simply stated. Aspose Tasks should function in exactly the same way as MSP when in MSP the user changes eg the end date as I am doing.After all isn’t this what you expect from Cells and Words. How that translates technically is up to Aspose to decide.

The user is setting actual dates and then reforecasting new end dates, progressing through the project, like you would expect a human to do. Initially the project is shifted and then it is adjusted until it is complete.

Also it should NEVER loop and use up all the memory on the machine.

You will note that I had a workaround already which was to use the critical path to force the intuitively correct recalculation and make it like MSP. This did not depend on knowing or working out which tasks needed automatic constraints. This may not be a perfect solution (eg there can be multiple crifical paths), but it does work in our case.

Again I do appreciate your efforts and it helps me understand the limitations and issues with Tasks when new things turn up as I suspect they will.


Regards

Richard



#31

Hi Richard,


We are sorry for a delayed response.

The issue of infinite loop, that used to consume all the memory of the machine, has already been identified and development team is working on it with thorough testing so as to avoid any such situation again.

As far as replication of MSP functionality is concerned, I have contacted the development team and will soon share my findings with you in this regard.

#32

Hi,

Many thanks for your continued support.

Regards

Richard
#33

Hi Richard,


Were you able to manage the other MPP file that is working fine in this case? We may need it as a reference for our development team to show them the differences for further investigation into this issue.
#34

Hi,


I have been traveling so have not been able to get back to you. Also I have discussed this with the customer.

As a developer I understand that making a requirement to have aspose work as mpp is probably quite an effort if that wasn’t the original idea. But certainly that was my expectation based on working with Cells and Words. Its also what the customer expects. It does seem to me to be a reasonable requirement of Tasks, however if you told me it was documented as a difference between MPP and Aspose, then that would be acceptble … rather than having to discover it by trial and error. Is it documented?

The bigger project does not have the issue simply because it does not have a non-ASAP constraint.

In fact for my customer it seems now that this is not what they intended either, it should be ASAP for all milestones. My solution now is to flag any projects with tasks that have such a constraint and not allow them to be used.

Again I thank you for your efforts. We will continue testing with this and similar projects.

Regards

Richard
#35

Hi Richard,


Thanks for writing again. Please spare me little time t review the documents. I will write back here soon to share my findings.

Your patience is highly appreciated here.

#36

Hi,


Actually I need more time too. We now detect the non-ASAP constraint and do not allow the MPP to be used until it is removed. Of course this solves the original problem BUT, now on the bigger project with more than 100 Tasks which never had the problem, we have a new issue.

The project manager is changing forecast and actual dates stepping through the project. But currently there is a backlog of existing projects to update (hundereds) ALL based on the same big MPP.

On the line: task.recalculate(tsk), it takes 40 seconds on the big project to recalculate the task that has been changed (on a 4 processor machine, very large RAM). Note we are always changing the start date and end date as these are milestones, and if they do have a duration it never changes.

This means to bring just one big project up-to-date will take 2 hrs which is unacceptable.

So now I am looking at some way to just save the dates and do a calculate once, at the end. We have to deliver something by Monday, so I dont have time to “sanitize” and send you the big MPP. Of course changing the dates in the MPP itself takes less than a second, so I have some explaining to do as to why with Aspose it takes 40 seconds.

BTW on the smaller project you have, after removing the offending constraint, the update is seemingly instantaneous to the user.

We will need help with this because the above solution is just short term, and is not what the user is expecting.

Regards

Richard





#37

Sorry, I should have made it clear, I am no longer doing the critical path / recalculate that I mentioned earlier because now the non-ASAp contraint is removd from the MPP, it is not needed.


I am simply recalculating the task for a single date change. Load the project, change to the new start date (and end date), and recalculate. Nothing else. I can see by stepping through the code that this takes the 40 seconds.

If you have any ideas please let me know, but I realize you will need a sample of the big project, but dont have time now as I have to make something acceptable immediately.
#38

Hi Richard,


I have created a new thread for your new issue here: http://www.aspose.com/community/forums/thread/483545/long-delay-on-task.recalculate.aspx

Please follow that for the new issue that you are facing.
#39

The issues you have found earlier (filed as TASKS-33381) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by Aspose Notifier.
#40

The issues you have found earlier (filed as ) have been fixed in this Aspose.Words for JasperReports 18.3 update.