Fog Creek Software
Discussion Board




Case numbers

In our group we have deployed FogBUGZ with MySQL and have been using it for couple of months now. According to the MySQL Control Center, we have a total of 74 cases. But in FogBUGZ, the case numbers for new cases are currently running in 400's.

Our case numbers were sequential until 63. Then they went to 80's, jumped to high 100's, skipped over 200's and went to mid 300's, and now are in low 400's.

Is this normal behavior? I was under the impression that the case numbers were sequential. We did delete couple of cases from the database back when we were playing with the Sample Project. Could that be the reason?

Sady
Tuesday, March 11, 2003

I can't speak for mySQL, but in MS SQL server, the answer to your question is yes.  The AutoNum does not revert down to the next available bug number if you delete the last 20.  It just keeps going where it's at.

Can you recall if your deletions of the sample bugs matched this pattern?

karan mavai
Tuesday, March 11, 2003

The reason why it would jump up so high is that the dispatcho mail retrieval program was unsuccessfully submitting cases to your server (maybe their was an email with an extra large attachment) and the case was being entered into fogbugz but the asp page was not OK'ing that it actually made it in.  To prevent from duplicate entries the dispatcho program would then tell fogbugz to delete the case if it accidentally did get added to the database (because dispatcho would try again later).  If you have your mail checking set to very frequently (in the mailboxes screen) and your server went down or there was a network slowdown or something, this could have been the cause.

Michael H. Pryor
Tuesday, March 11, 2003

Reply to Karan: The couple of sample cases we manually deleted were like case numbers 2 and 3. The new case numbers continued from where the counter stood last. But we never manually deleted any cases after that.

Reply to Michael: That sounds possible. The time we started using mailboxes in FogBUGZ is pretty close to the time when the case numbers started jumping. Given the jumps we have, it seems like this scenario happens pretty frequently at our site. We currently have 3 mailboxes that are polled every 15 minutes. I don't believe the emails sent are huge - they would typically be less than 1M. Any ideas how to address this issue?

Sady
Tuesday, March 11, 2003

If the problem is because of too-large emails that take too long to submit to FogBUGZ, it may be possible to increase the timeout settings in IIS beyond the default 30 (?) seconds.

Joel Spolsky
Saturday, March 15, 2003

I don't believe the emails to our FogBUGZ mailboxes are huge. Until now they are actually less than 300K.

How to increase the default timeout in IIS?

This continues to be a big problem for us. We now have about 90 cases, but our case numbers are already approaching 800. Any help is appreciated.

Sady
Monday, March 17, 2003

As soon as Michael gets back from vacation at the end of this week he's going to work on fixing this...

Joel Spolsky
Tuesday, March 18, 2003

Was this ever addressed?  We're running 3.0.5 and have pretty large email attachemnts (screen shots) and have mail pulling very frequently (we have everyone doing QA use email to send in bugz instead of using the web becasue it is easier for the screen shots) and our cases jumped from 235 - 1500 - 1800 very quickly.

Zip
Friday, May 09, 2003

I tracked down the problem. An email was sent with a 1.3M attachment to one of our FogBUGZ email boxes. Dispatcho kept trying to publish the email as a FogBUGZ case, but failed. Every time it failed, the case number gets incremented.

I had to read about MySQL configuration and found that there is a variable called max_allowed_packet. It is set to 1M by default. I changed it to 32M and now Dispatcho is able to publish the email. This fixed the jumps in case numbers.

Sady
Wednesday, May 21, 2003

What's the fix for SQL Server?

Richard Lawrence
Monday, June 09, 2003

*  Recent Topics

*  Fog Creek Home