Error 500 while reporting, updating, ...

[fxm]

Hi all,

First of all: best wishes for all of you ...

My problem: I have a Mantis installation wich migrate from 1.2.1 to 1.2.8 and since this moment (I think), I get error 500 (in IIS log file) while I report, update, delete, ... an issue. Note that issue is well reported, updated, deleted, ... but user gets a blank page after a while.

I notice that problem is linked to data (from the DB) since I make a new empty installation and all works fine until I inject "old" DB content into new installation.

Can somebody tell me how I can find the guilty data ? How can I diagnose this issue ?

Thanks for all of your tips.

Regards,
François (Belgium)

Mantis 1.2.8 on IIS 6 (Win Server 2003)

[fxm]

Re-Hello,

I activate Logging without success (no logging at all).

Code: Select all

	$g_display_errors = array(
		E_WARNING => 'inline',
		E_NOTICE => 'inline',
		E_USER_ERROR => 'inline',
		E_USER_WARNING => 'inline',
		E_USER_NOTICE => 'inline'
	);	
	
	$g_log_level = LOG_AJAX | LOG_DATABASE;
	$g_log_destination = 'file:D:/temp/mantisbt.log';

Please if any idea ...

[atrol]

You have to add the following lines to config_inc.php if you want to trace database in version 1.2.x

Code: Select all

$g_show_queries_count = ON;
$g_show_queries_list = ON;

[fxm]

Here follows the result. As I cannot "translate" this logging, I post it in order to have support.

Code: Select all

19-01-2012 11:50 CET database array (
  0 => 'SELECT last_modified
		          	FROM mantis_bugnote_table
		          	WHERE id=0',
  1 => '0.0002',
  2 => 'bugnote_api.php:318 bugnote_get_field()',
)
19-01-2012 11:50 CET database array (
  0 => 'SELECT *
				  FROM mantis_user_pref_table
				  WHERE user_id IN (1) AND project_id=1',
  1 => '0.0003',
  2 => 'user_pref_api.php:221 user_pref_cache_array_rows()',
)
19-01-2012 11:50 CET mail_recipient Issue = #679, drop @U1 (own)
19-01-2012 11:50 CET database array (
  0 => 'SELECT email_id FROM mantis_email_table ORDER BY email_id DESC',
  1 => '0.0153',
  2 => 'email_queue_api.php:176 email_queue_get_ids()',
)
19-01-2012 11:50 CET database array (
  0 => 'SELECT * FROM mantis_email_table WHERE email_id=254',
  1 => '0.0118',
  2 => 'email_queue_api.php:148 email_queue_get()',
)

Note that last select returns an email send to a deactivated user ...

[atrol]

Add the following lines to config_inc.php to trace how MantisBT collects and removes the recipients

Code: Select all

$g_log_level = LOG_EMAIL | LOG_EMAIL_RECIPIENT;
$g_log_destination = 'file:D:/temp/mantisbt.log';

Note that last select returns an email send to a deactivated user ...

And there is no issue if you activate the user?

[fxm]

The lines you mentioned were already added.

Note that If I truncate the mantis_email_table the site is working fine back.

So can you tell me what is this table ?

Thanks for your support,
François

[atrol]

I don't have the time to write a detailed description how MantisBT handles email. (and the one and only truth is always the source code)
Some information which might help to understand what's happening
http://www.mantisbt.org/forums/viewtopi ... =2&t=20031
http://www.mantisbt.org/wiki/doku.php/m ... il_queuing

You have to find out why some mails can't be delivered.
If you don't find the cause you will get the problem again and again.
IMO setting up a cronjob to deliver helps in short term, but in long term your mantis_email_table will grow and the cronjob will slow down your system.

[fxm]

You reply is very clear and I understand the cause: email address is no more valid.

Can you tell me if there is a way to avoid filling mantis_email_table (because we don't need usage of cronjob).

Much thanks for your explanations.

Regards,
François

[atrol]

Can you tell me if there is a way to avoid filling mantis_email_table (because we don't need usage of cronjob).

You have to change source code of email_api.php

Seems you didn't understand the concept behind the email queue in mantis_email_table.
MantisBT always uses mantis_email_table.
If you use cron, the mails are collected and sent every let's say 10 minutes.
If you don't use cron, the mails for all recipients are collected and sent immediately when you report or update an issue.