2.6.0 production -- slow response -- what changed?

Ok. got tired of the word Beta in the console. did a complete uninstall, reinstall of the server instance this morning. I did save all of my stuff to replace with, but as of this moment only used the wildfire.xml file and I tweaked the VM mem in the start script.

Question: what has changed from 2.5.1/2.56.0 beta to make logging in so s-l-o-w, slower actually than 2.5.1 inital login… I do see in the logs it looks like it is starting a whole new cache, rightfully as the installation is fresh at the moment (not knowing anything and trying to cache info). I can log into the Admin webpage without issue, all of that seems normal (as per 2.5.1 and 2.6.0 beta), but hooking a client up… man…phew… I can see in the console that it has authenticated me, show ip client info etc, but the clients sit there looking like they are hung up. Same client that was configured yesterday that logged in and ran great… Any Ideas out there guys?

Jeff

ok 10 minutes and counting…

Message was edited by: jeff_garner

going to reboot the entire box. This is painful…

Message was edited by: jeff_garner

Alright guys… I am not a DBA, but I booted the box, and then went about restarting the pgsql database, then started wildfire and the first thing I see is this:

ERROR: relation “pubsubdefaultconf” does not exist

ERROR: relation “pubsubdefaultconf” does not exist

ERROR: relation “pubsubdefaultconf” does not exist

ERROR: relation “pubsubdefaultconf” does not exist

ERROR: relation “pubsubnode” does not exist

ERROR: relation “pubsubnode” does not exist

ERROR: relation “pubsubaffiliation” does not exist

ERROR: relation “pubsubsubscription” does not exist

Looks like it attempted another database upgrade? Maybe, it didn’'t work so well…

question, did this just hose the database?

UPDATE: 22 minutes from restart I have now successfuly logged into the server… that was 22 minutes of letting the client sit there and ‘‘hang’’ until finally it was allowed in…

Message was edited by: jeff_garner

Hi Jeff,

Can you log into your database and see if you have the following tables:

pubsubdefaultconf

pubsubnode

pubsubaffiliation

pubsubsubscription

Thanks,

Ryan

FYI, I ran into this problem… Look in your … I think it’‘s error.log? Either way, I ran into an error where Wildfire was trying to upgrade one of the varchar columns in one of the tables to something larger than what’‘s allowed. (> 255 chars) Note that this is an issue with older MySQL (I was running 4.0.2something) I upgraded my MySQL install to the 5.0 series and Wildfire cheerful upgraded it’‘s databases and was pleased. I also had nasty slowness before I did this. (I don’'t know what the lower-end threshold is for MySQL) Anyway, long story short, I wonder if something similar is going on with your postgres setup and maybe it requires a postgres update?

No, those are not in there.

Running Postgresql 8.1.3

I have around 16 or so jive~ tables

5 muc~ tables

two phone~

Should I have them?

wildfire=# \d

public | jiveextcomponentconf | table |

public | jivegroup | table |

public | jivegroupprop | table |

public | jivegroupuser | table |

public | jiveid | table |

public | jiveoffline | table |

public | jiveprivacylist | table |

public | jiveprivate | table |

public | jiveproperty | table |

public | jiveremoteserverconf | table |

public | jiveroster | table |

public | jiverostergroups | table |

public | jiveuser | table |

public | jiveuserprop | table |

public | jivevcard | table |

public | jiveversion | table |

public | mucaffiliation | table |

public | mucconversationlog | table |

public | mucmember | table |

public | mucroom | table |

public | mucroomprop | table |

public | phonedevice | table |

public | phoneuser | table |

Jeff

Message was edited by: jeff_garner

Message was edited by: jeff_garner

Hi Jeff,

Should I have them?

Yes, you should, there should actually be 5 pubsub* tables, the four I listed above plus “pubsubItem”. There’‘s a couple of things I’'d like for you to try.

  1. Execute a “\d jiveproperty”. I’'m curious to know the size of the propValue field.

  2. Exectue a “select * from jiveversion”. We need to know what version Wildfire thinks it is.

Thanks,

Ryan

Table “public.jiveproperty”

Column | Type | Modifiers


*----


*----


name | character varying(100) | not null

propvalue | character varying(4000) | not null

Indexes:

“jiveproperty_pk” PRIMARY KEY, btree (name)

wildfire=# select * FROM jiveversion

wildfire-# ;

majorversion | minorversion


±—


2 | 5

(1 row)

I think I have found an issue with me as well. This is a Fedora system. It still has an original 7.4 version of psql on it. I manually start postgres when I boot the box, and prior to that there is none running. I manually give my path to the 8.1.3 installation and it starts, but I never really looked at it, but two seperate groups of postmaster are running if I do a ps -A… java is sitting right above or below the last grouping of postmaster. I wonder if 7.4 is starting with Wildfire and when I installed this time, 2.6 saw the other one and said that’'s the one to use…hmmmm.

Hey Jeff,

What version of pgsql are you using? I found a problem in an upgrade script that fails to run under pgsql 8.0. I can send you a modified version of the server or you can try doing the following:

  1. Stop the server

  2. Restore db that you were using with 2.5.1 or with your 2.6.0 beta

  3. Replace resources\database\upgrade\6\wildfire_postgresql.sql with the attached one

  4. Execute resources\database\upgrade\6 upgrade script.

  5. Execute resources\database\upgrade\7 upgrade script.

  6. Start the server

By manually running steps 4 and 5 you will be able to check that upgrade scripts were executed successfully or you will get a clear vision of what errors are happening.

Once you have confirmed that things are working fine we are going to release a new version of the server so admins don’'t have to do this work manually.

Thanks,

– Gato

Hey Jeff,

I forgot of this last step:

  1. Execute UPDATE jiveVersion SET version=7 WHERE name=’‘wildfire’’

  2. Start the server

Regards,

– Gato

Looks like Gato is on-the-case.

Hey Ryan,

This thread is pretty active. When I first read it there were only 3 replies and I then started to study the case. After I replied I checked the thread and noticed that there were many other replies before mine.

Saludos,

– Gato

Hi Gato,

No worries - I know how quickly things move around here.

Cheers,

Ryan

ok. I will start these steps. One question, what if I can’‘t find (here’'s my real opps for the day) the original wildfire database from 2.5.1. As this wasn;t a production system I wasn;t all that diligent on doing a PG_dumpall as I should have been…

let me know if I should continue with what you gave , on the current database, or do I need to start from scratch? Starting from Scratch isn;t a big deal, I just have to inform my testers.

Jeff

running psql 8.1.3

confirmed in wildfire, it is running 8.1.3 as the database.

Message was edited by: jeff_garner

Does this also apply to MySQL?

I tried to do an upgrade from 2.5.1 to 2.6.0 with bad results.

If I run the configuration wizard, or copy my original wildfire.xml to the conf directory, I can’'t log into the admin console. It keeps telling me the password is incorrect.

Report bugs to pgsql-bugs@postgresql.org.

bash-3.00$ /usr/local/pgsql/bin/psql -d wildfire -f ./wildfire_postgresql.sql

DROP TABLE

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “jiveversion_pk” for table “jiveversion”

psql:./wildfire_postgresql.sql:10: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “jiveversion_pk” for table “jiveversion”

CREATE TABLE

INSERT 0 1

ALTER TABLE

ALTER TABLE

bash-3.00$ ls

wildfire_db2.sql wildfire_oracle.sql wildfire_sybase.sql

wildfire_hsqldb.sql wildfire_postgresql.sql

wildfire_mysql.sql wildfire_sqlserver.sql

bash-3.00$ cd …/7

bash-3.00$ ls

wildfire_db2.sql wildfire_oracle.sql wildfire_sybase.sql

wildfire_hsqldb.sql wildfire_postgresql.sql

wildfire_mysql.sql wildfire_sqlserver.sql

bash-3.00$ pwd

/opt/wildfire/resources/database/upgrade/7

bash-3.00$ /usr/local/pgsql/bin/psql -d wildfire -f ./wildfire_postgresql.sql

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubnode_pk” for table “pubsubnode”

psql:./wildfire_postgresql.sql:42: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubnode_pk” for table “pubsubnode”

CREATE TABLE

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubaffil_pk” for table “pubsubaffiliation”

psql:./wildfire_postgresql.sql:50: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubaffil_pk” for table “pubsubaffiliation”

CREATE TABLE

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubitem_pk” for table “pubsubitem”

psql:./wildfire_postgresql.sql:60: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubitem_pk” for table “pubsubitem”

CREATE TABLE

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubsubs_pk” for table “pubsubsubscription”

psql:./wildfire_postgresql.sql:79: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubsubs_pk” for table “pubsubsubscription”

CREATE TABLE

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubdefconf_pk” for table “pubsubdefaultconf”

psql:./wildfire_postgresql.sql:101: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “pubsubdefconf_pk” for table “pubsubdefaultconf”

CREATE TABLE

Does this look correct ?

Jeff

wildfire=# \d jiveversion

Table “public.jiveversion”

Column | Type | Modifiers


*----


*----


name | character varying(50) | not null

version | integer | not null

Indexes:

“jiveversion_pk” PRIMARY KEY, btree (name)

wildfire=#

wildfire=#

wildfire=#

wildfire=# SELECT * FROM jiveversion

wildfire-# ;

name | version


±—


wildfire | 7

(1 row)

Message was edited by: jeff_garner

wildfire=#

wildfire=# \d

List of relations

Schema | Name | Type | Owner


*----


*-----+


public | jiveextcomponentconf | table |

public | jivegroup | table |

public | jivegroupprop | table |

public | jivegroupuser | table |

public | jiveid | table |

public | jiveoffline | table |

public | jiveprivacylist | table |

public | jiveprivate | table |

public | jiveproperty | table |

public | jiveremoteserverconf | table |

public | jiveroster | table |

public | jiverostergroups | table |

public | jiveuser | table |

public | jiveuserprop | table |

public | jivevcard | table |

public | jiveversion | table |

public | mucaffiliation | table |

public | mucconversationlog | table |

public | mucmember | table |

public | mucroom | table |

public | mucroomprop | table |

public | phonedevice | table |

public | phoneuser | table |

public | pubsubaffiliation | table |

public | pubsubdefaultconf | table |

public | pubsubitem | table |

public | pubsubnode | table |

public | pubsubsubscription | table |

(28 rows)

wildfire=#

Message was edited by: jeff_garner

Message was edited by: jeff_garner

Hey Jeff,

That looks correct. Database has the correct structure now. How are things working now?

Regards,

– Gato

Look at the third reply to my issue. There is something dealing with MySQL…

Jeff

Message was edited by: jeff_garner

Hey Pixel,

MySQL should be upgraded automatically without any problem unless you are using MySQL 4.0.* that by default won’'t allow fields bigger than 255 characters. In that case, I would recommend upgrading to MySQL 5.0 or at least MySQL 4.1.18.

Regards,

– Gato

so far this is all I am getting in the error log… remember we talked about this yesterday. this was a fresh install this morning, I rm’'d the directory before installing 2.6.0 at 6:30 am. all new errors

Jeff

java.lang.NullPointerException

2006.04.07 11:44:27 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 11:52:13 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 11:54:16 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:01:00 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:10:30 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:34:53 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:35:08 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:43:52 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 12:52:00 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 13:07:36 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 13:08:25 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 13:08:50 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 13:09:59 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 13:10:14 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

2006.04.07 14:27:45 [org.jivesoftware.wildfire.ldap.LdapManager.(LdapManager.java:183)] Initial context factory class failed to load: com.foo.factoryClass. Using default initial context factory class instead.

2006.04.07 14:28:32 org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java:1 80)

java.lang.NullPointerException

at org.jivesoftware.wildfire.ldap.LdapUserProvider.getUsers(LdapUserProvider.java: 173)

at org.jivesoftware.wildfire.user.UserManager.getUsers(UserManager.java:194)

at org.jivesoftware.wildfire.roster.RosterManager.getSharedUsersForRoster(RosterMa nager.java:701)

at org.jivesoftware.wildfire.roster.Roster.getSharedUsers(Roster.java:514)

at org.jivesoftware.wildfire.roster.Roster.(Roster.java:110)

at org.jivesoftware.wildfire.roster.RosterManager.getRoster(RosterManager.java:92)

at org.jivesoftware.wildfire.user.User.getRoster(User.java:280)

at org.jivesoftware.wildfire.handler.IQRosterHandler.manageRoster(IQRosterHandler. java:187)

at org.jivesoftware.wildfire.handler.IQRosterHandler.handleIQ(IQRosterHandler.java :104)

at org.jivesoftware.wildfire.handler.IQHandler.process(IQHandler.java:48)

at org.jivesoftware.wildfire.IQRouter.handle(IQRouter.java:265)

at org.jivesoftware.wildfire.IQRouter.route(IQRouter.java:96)

at org.jivesoftware.wildfire.PacketRouter.route(PacketRouter.java:65)

at org.jivesoftware.wildfire.net.SocketReader.processIQ(SocketReader.java:396)

at org.jivesoftware.wildfire.net.ClientSocketReader.processIQ(ClientSocketReader.j ava:50)

at org.jivesoftware.wildfire.net.SocketReader.readStream(SocketReader.java:264)

at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:119)

at java.lang.Thread.run(Unknown Source)

5 minutes and it is still timing,. we hit 22 minutes this morning. Wildfire is doing another cache refresh…

How many times will it do this, is this the after installation one all over or can I expect it 2 times or 3 times a day? No way will this fly with management…

Jeff

this login took about the same time. approx 21 minutes. when I get home, will dial in and see if it improves.

Jeff

Gato, Ryang thanks for your help today. gotta run will check this thread later…

Message was edited by: jeff_garner