JasperReports Server 4.0.0 - BUG - Repeatedly sends email

[billmelotti]

Hi

 

I have upgraded from 3.7.0 server to 4.0.0 and I am testing all the reports I had scheduled under 3.7.0.

When the reports run, they should generate email with report attached.

I am receiving multiple copies of these emails and it is not stopping !  The time periods seem a bit random, but one report is being emailed roughly 4 times an hour. Others seems less than that, but are definitely repeating. I have about 60 or so emails this morning from an overnight run of about 5 reports spread from midnight to 4am.

Where I look in the repository in the folder I told it to store the finished reports, it is filling this up with many reports. Each of the generated reports has a unique timestamp, so this suggests it is re-running the whole process, rather than just retrying the email.

I believe this is a bug, the schedule I setup under 3.7.0 is exactly the same and works fine. Basically I ran the upgrade DB scripts

 

BTW Is there somewhere else I should be posting queries like this? I never seem to get an answer on these forums....

 

Regards Bill Melotti

[billmelotti]

Hi again

 

Actually now I've gone through all my reports, its worse than I first suggested. Some reports didn't run at all, some ran twice or three times, on in such quick succession the server had problem saving files as in that case they had same timestamp.

The server GUI claims the last runtime of a report was in fact the first time it ran. The repeats, although they get different timestamps, don't update the GUI with the latest runtime.

And one reports loops, roughly every 15 mins.

To do this upgrade test I had cloned my 3.7 setup onto another server, with newer OS. Unfortunately it also had MySQL5.5 which I didn't find out until later. I never ran the cloned 3.7 setup to see if it was OK just did a straight upgrade and tested that, so I'm now planning to downgrade MySQl, clone 3.7 again, run for a week, then upgrade to 4.0, run for another week and report futher problems here.

 

[ernestoo]

Hi Bill,

 

When you say "clone" are you doing a MySQL dump of the tables in your database and then pointing 4.0 to them or something?

 

The upgrade process is via the import-export tool described in the Install Guide. Is that the procedure you followed? I haven't heard of anyone having this problem.

 

Are you seeing any errors in your logs?

[ramnik]

Sorry for the all issues.

This is BUG in 4.0. which is fixed in 4.0.1

Please use this to solve the issue. It is minor configuration setting that will help you fix the issue :-

Please update the \WEB-INF\js.quartz.propertiesorg.quartz.jobStore.clusterCheckinInterval = 15 minExplanation:-This value sets the interval(from start time of executing job) at the end ofwhich the recover job will fire. It is very import in the case of clustering:Ifjob will failed on the one cluster node(For example in the case of applicationstopped on the node) then it will be successfully recovered on the othernode(per clusterCheckinInterval).I increased this value to 15 min because for complex report(time executing isbig) time of job executing will be able more than 10 min and then recoveringjob will result the problems (such as in bugs#22057, 22045, 22058). So, for cutomer we will documented it and in additionally:"..When you have smaller or bigger executing report time than 15 you willdecrease or increase appropriately this value for correct job recoveringwork.." [/code]

 

hope it helps,

Ramnik Kaur

Senior QA Engineer

[billmelotti]

Thanks for the two replies folks.

I'll try the config change see what it does. I'm not running in a cluster anyway so I guess I set that value quite high.

I did not look at the log this time. The looping report occurred yesterday (a slightly different version of it runs on Wednesday only) and restarting the server fixed it, I thought perhaps it was a one off. The log showed nothing then, so I didn't bother looking with yesterday's multiple problems.

After yesterday's problem, I abandoned the test setup I had (as it inadvertently used MySQL5.5) and I will be restarting my upgrade tests on 11th April with a more appropriate version of MySQL.... I'll let you know what happens.

BTW When using 5.5 not only do you have to quote some of the statements in upgrade scripts, but it seems report Input Controls use the phrase 'maxValue' in their XML configs, so any report making use of this will not import in the upgrade process. I guess this needs fixing too in 4.0.1?

 

WRT to the earlier comment about cloning, I simply shut down my 3.7 server and glassfish container, then tarred up the java dir, glassfish dir, plus dumped DB contents. On a different server I unpacked the dirs, created a jasperserver db and imported data. Superficially it appeared OK, so then I tried upgrading it. At this this way I didn't mess up my 3.7 setup.

I'm so glad I did, as a java/glassfish newbie I had to re-create that clone many times while trying to understand the upgrade process.

 

[billmelotti]

Hi again

 

I have started re-running my tests with a better version of MySQL. I set the property in js/quartz file as suggested

 

This has made no difference, the server is still repeatedly emailing reports.

 

Can anyone help with this and/or is there any date for JasperReports Server 4.0.1 being released?

 

Many thanks

 

[jlematire]

 did you ever get an answer or reach a resolution on this? because we have been experiencing the exact same behavior.

[ernestoo]

From an internal forum:

===

The problems are caused by a Quartz bug: 
http://jira.opensymphony.com/browse/QUARTZ-280. The bug causes jobs to 
be executed twice if the Quartz cluster manager thread performs a 
cluster checkin during a report job execution. 

If JRS is not actually clustered, changing 
org.quartz.jobStore.isClustered to false in js.quartz.base.properties 
avoids the bug. If JRS is clustered, increasing 
org.quartz.jobStore.clusterCheckinInterval would decrease the frequency 
of the double report executions (but it would also increase the recovery 
time in cases in which a node actually fails). 

===

Can someone verify this?

[jlematire]

 we put this change in and JRS has not sent a duplicate in over 2 weeks, which is a record. So we think we may be out of the woods, although I probably just jinxed the whole thing!