CustomField -> QueueObj deprecated error when migrating 3.0.8 to 3.4.3

Hi,
I couldn’t find the answer to this in the archives, but hopefully
someone knows what is causing this:

I’m in the process of upgrading to a new RT server on a new machine
(3.0.8 to 3.4.3). I did a mysqldump from 3.0.8 machine using this
command as suggested in the archives:
#mysqldump --complete-insert --add-drop-table rt3 > rt3dump

I then transfered the file to the new RT 3.4.3, created an empty mysql
DB called ‘rt_test’, and imported using something like this:
#mysql rt_test -uroot -p < rt3dump

Then, following directions in the README of 3.4.3, I ran the
rt-setup-database script 3 times (once for schema, acl, insert) for each
version it told me to (3.1.0, 3.1.15, 3.1.17, 3.3.0, 3.3.11):
#/opt/rt3/sbin/rt-setup-database --action schema
–datadir etc/upgrade/
#/opt/rt3/sbin/rt-setup-database --action acl
–datadir etc/upgrade/
#/opt/rt3/sbin/rt-setup-database --action insert
–datadir etc/upgrade/

Everything seemed to go smoothly. Restarted apachectl. Logged in fine,
looked like everything was there and worked good. So then I click on a
queue, then open a ticket, and then I click “Tickets” to go back to the
queue listing, and it hangs for a couple minutes and I get this error in
the log multiple times:

…RT::CustomField -> QueueObj deprecated
(/opt/rt3/lib/RT/CustomField_Overlay.pm:753)

Here are the log entries a couple seconds before it:

[Fri Sep 9 02:37:28 2005] [debug]: About to think about scrips for
transaction #231656 (/opt/rt3/lib/RT/Transaction_Overlay.pm:156)
[Fri Sep 9 02:37:28 2005] [debug]: About to prepare scrips for
transaction #231656 (/opt/rt3/lib/RT/Transaction_Overlay.pm:160)
[Fri Sep 9 02:37:28 2005] [debug]: Found 2 scrips
(/opt/rt3/lib/RT/Scrips_Overlay.pm:356)
[Fri Sep 9 02:37:28 2005] [debug]: About to commit scrips for
transaction #231656 (/opt/rt3/lib/RT/Transaction_Overlay.pm:169)
[Fri Sep 9 02:37:33 2005] [debug]: RT::CustomField -> QueueObj
deprecated (/opt/rt3/lib/RT/CustomField_Overlay.pm:753)

last line repeated a bunch…

Anyway, anybody know what I did wrong? Is it a Custom Field, Template,
or Scrip from the old DB that needs to be removed from the dump file? I
read something about clearing out the mason data and session cache,
could that be it? best way to do that?
FYI, I had to downgrade HTML::Mason from 1.31 to 1.28 to get RT 3.4.3 to
work on my setup: RHEL4, apache2, fastCGI.

Sorry for all the questions,
Thanks for any info though!

Mark Matyas

[snip]

[Fri Sep 9 02:37:33 2005] [debug]: RT::CustomField → QueueObj
deprecated (/opt/rt3/lib/RT/CustomField_Overlay.pm:753)

It’s not an error – see the [debug] part? It’s a warning that the
underlying API has changed, not that anything is broken. You can safely
ignore it.

  • Alex

[snip]

[Fri Sep 9 02:37:33 2005] [debug]: RT::CustomField → QueueObj
deprecated (/opt/rt3/lib/RT/CustomField_Overlay.pm:753)

It’s not an error – see the [debug] part? It’s a warning that the
underlying API has changed, not that anything is broken. You can safely
ignore it.
You can’t ignore it if RT::CustomField → QueueObj is used in your
code. In next versions this function will disappear.

  • Alex

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Buy your copy of our new book, RT Essentials, today!

Download a free sample chapter from http://rtbook.bestpractical.com

Best regards, Ruslan.

You can’t ignore it if RT::CustomField → QueueObj is used in your
code. In next versions this function will disappear.

Sure. If you want to know what’s causing them, try the attached patch.

  • Alex

deprecated.patch (1.58 KB)

May be you will apply to mainline LogStackTraces patch I sent? :)On 9/10/05, Alex Vandiver alexmv@bestpractical.com wrote:

On Sat, 2005-09-10 at 02:30 +0400, Ruslan Zakirov wrote:

You can’t ignore it if RT::CustomField → QueueObj is used in your
code. In next versions this function will disappear.

Sure. If you want to know what’s causing them, try the attached patch.

  • Alex

Best regards, Ruslan.

[snip]
Please keep these discussions on the lists so others can benefit.

I would like to ignore it, but it actually makes RT unuseable for a
couple minutes … Can’t login, can’t do anything.

I also get this multiple times in the httpd error log when it happens:

[Fri Sep 09 15:16:04 2005] [info] (32)Broken pipe: core_output_filter:
writing data to the network

Is it something with the apache handler then?

…no, this is a bug in apache2, not RT – googling show no obvious
solution. I would suggest running under apache1.3, or trying fastcgi.

  • Alex

…no, this is a bug in apache2, not RT

Does Error Messages - Frequently Asked Questions - Apache HTTP Server fix
the issue for you?

  • Alex