 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Tom Jacob - 17/Mar/08 02:13 PM
Attaching the junit xml report file that pulse failed to process
Hi Tom,
Thanks for the very detailed report; this made the problem very easy to track down. Essentially, the JUnit report post-processor is assuming the existence of a detail message for failed test cases. It actually tries to check for the existence of the message first, but in an incorrect way. Thus if your report has a test failure or error XML element that does not have text content, the post-processor fails. I have reproduced this with a test case and can fix it quite easily. We can make a new build available for you this week so you are not held up any longer. Sorry for the trouble! Hi Tom,
I forgot to confirm that the HTML report not being captured is almost certainly due to the earlier problem. I also took a look at the XML report you just attached (thanks) and found there were indeed some <failure>s with no nested text, which would trigger this problem. It seems that JUnit itself always produces detail messages, which is why we have not uncovered this bug until now. Hi Jason,
Thank you very much for looking at this issue on priority. Look forward to the next release build with fix. Am I right in assuming that I'll get the version 1.2.49 for download from http://zutubi.com/products/pulse/downloads/ sometime this week or is there a separate location for downloading nightly builds? Oh another question I have is - Is there any way I can just use the new core-1.2.x jar file and not re-install/upgarde the whole product? Thanks again for the great support. Hi Tom,
No problem! The 1.2.49 release will indeed be available from our website downloads page. We like to do frequent builds (and since it is all automated with our own Pulse install it is easy enough :) ), every one of which is a full release. We do not currently do nightlies - although it is something we will probably add one day as it is again simple to schedule in our own Pulse install. You might be able to drop in the new core jar, but there will be a few other changes some of which span other jars so it is not guaranteed to work. Actually, upgrading the whole install is extremely simple - you just need to backup, then unpack and start the new version and point it at your existing data. If there are any schema upgrades (in this case I don't believe there will be), Pulse will show you an automatic schema update page and after running through that things will be going again. Hi Tom,
Just FYI: Pulse 1.2.49 is now available from http://www.zutubi.com/products/pulse/downloads/. It includes a fix for this issue. hi Jason,
Thanks. I did get the update installed and the system is now able to parse the JUnit Xml test results properly. But, the updated software when pointed to the old data directory did not show the existsing projects as I expected. So, after a few attempts I had to manually redo the whole lot. Aside from that, we have had a new issue, namely, getting build failures due to "connection to agent lost" error. I reckon this happened about 3 to 4 times since I've installed. I have looked into the bug list and find that this has been raised before and is explained as an artifact of faulty/unavailable network. All of our other network apps are working Ok and we coldn't find anything of interest happening on the network during these failures. So, this is a cause for concern for us, and we've decided to trial run pulse in parallel with out existing tool for a month and collect statistics to properly analyze the risk due to this vulnerability (which may be due to the network flakiness) before we make a decision on replacing our existing tool with pulse. On account of this exercise I'd like to request you for an extension of our trial period (which ends on the 6th) by a month if that is possible. I'm not sure if you are right person to contact in this regard. Apologies if you are not and could you in that case please direct me to someone who can speak on commercial aspects. Hi Tom,
Good to hear that this fix works for you. However, it is not so great to hear of your upgrade troubles (particularly after I said it was so simple)! It seems something unusual happened in your environment, as this is certainly not expected. May I ask some questions to try and track this down? Specifically: 1) Did you do the upgrade as the same user that was running Pulse? 2) When you installed the new version, what setup steps did you see? Steps include: - prompt for data directory - license page - admin user page - server settings page 3) What does the original data directory look like? Has it been replaced with current data? Re: connection lost issues, this has been caused in the past by network reliability issues and also very high load on agents during builds. An agent is determined to drop offline if it fails to respond to a master ping within a certain timeout. There are parameters you can tune: the ping frequency and timeout. See: http://confluence.zutubi.com/display/pulse0102/System+Properties for details. If problems persist then we can help you with extra debugging. Lastly, I will email you directly regarding the license. Hi Jason,
Thanks again for the extended license. On the issue of lost data, answers to your queries are: 1. yes, i did do the install as the same OS user as the one running pulse 2. what I did to upgrade was: backedup the old pulse data directory and mv-ed the pulse-agent* directory extracted the new pulse agent tar started pulse; and it started up with ~<userhome>/.pulse as the data directory. So, I stopped the server and restarted with -d pointing to the original pulse_data directory. This time it did refer to the new data directory but saidy "empty database, initializing.." or something similar. I logged in and found no projects. btw, it did not prompt for data directory (presumably as I had set it from command line?) and went straight to the license prompt and onwards as you have described. 3. Sorry, but I have since deleted the copy of the old pulse_data folder. As to the new one, yes it has only new config in it. Re: the connection lost issue, which is more important from our perspective - This issue did occur over the weekend again. This time connection to the agent seems to have been lost during the checkout from subversion. The server log does show a ping timeout at the same time as the connection loss is reported on the build log, so I'm refraining from opening up another issue as you seem to think this is not a pulse issue. So, I've decided to modify the ping.timeout and interval values as you have suggested. But, was wondering if you had any recommendations on how the interval and timeout params should be used in this case. I'm contemplating increasing the timeout and decreasing the interval so that there are multiple pings attempted within the timeout period; which I hope will give it a better chance at getting a reply back. I'm assuming here that the ping and it's reply is a custom hearbeat check that you have built into the masters/agents and does not have a big network footprint. Your comments/recommendations on this would be much appreciated. Hi Tom,
OK, using the same user simplifies things. From your description, I think the problem may have been an incorrectly-specified data directory. The default data directory suggested by Pulse is $HOME/.pulse/data, not $HOME/.pulse. Pulse does put a config file in $HOME/.pulse to hold configuration values that are required before starting the web UI, but this file is not part of the $PULSE_DATA. So your steps all sound right except that the data/ part of the directory was omitted when starting the new version with -d, leading Pulse to think that there was no existing data. Re: agent pings, any failed ping will cause the agent to be marked offline, so making them more frequent will not help. In fact, if there is a long delay waiting for a response the agent should not be pinged again until the response arrives or a timeout occurs. So I would recommend a setting where your ping timeout is longer than the average. The ping interval may also be set longer to reduce the chance of a bad ping, although this will not in itself solve any underlying problem. The fact that the timeout occured during the checkout is interesting. I doubt there was much load on the agent due to checkout which suggests that CPU overload is not the issue. Is the Subversion server across the same network? Perhaps the collision in traffic (check + ping simultaneously) makes a timeout more likely. The pings are lightweight so should not create a lot of network load, but it is still something to keep an eye on (especially if this happens during checkouts at other times). |
||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Pulse build errors out during Junit XML artifacts processing
