[esb-issues] [JBoss JIRA] Commented: (JBESB-1675) Possible Juddi Performance problems

Tue Apr 29 15:21:09 EDT 2008

    [ http://jira.jboss.com/jira/browse/JBESB-1675?page=comments#action_12411215 ] 

Vinicius Carvalho commented on JBESB-1675:
------------------------------------------

Tom, I would like to add a server output log to this in order to help, but I have some very, very frighting numbers.
After JBoss starts with trace log for juddi, log goes to 50M just for start (and sometimes, the selects takes so long, that I'm having issues with deployment, some beans do not even deploy).

Ok, first test: Access the /contract page. result = 30M of log, and over 120 seconds waiting for the page (for every request)

Second test, send an message to the ESB. Result = 100M of log, over 40 seconds for a response.

I'd like to note, that the database (the entire juddidb) has 973 rows, the sum of all rows in the catalog.

When we clean the database, our log stays bellow 2M, response time for a ESB message is between 1 and 2 seconds (max), and as I'm writing this, JBoss is trying to stop for over 6 minutes now, over 200M of log have been generated and every line is related to juddi sql statements.

I could post the server.log, but I guess (since its over 300M now) it will be bigger than the maximum attach file size. 

Well, I can post numbers as soon as I analyze the log with some sort of awk/grep combination (like, how many statements per scenario: startup, contract, service invoking, shutdown), I could past some parts of the output as well

Also, we had 2 vm crashes due to network problems, when we checked the hs_err log, we checked the the reason was.... JUDDI (man I hate this thing already)

We are using the default ESB config, we only changed database access, we are using mysql 5.0 as our SGDB. 

What else do you guys need? would you want our jboss-esb.xml file? As I said before we have only 14 services, how could be so many selects. I can't imagine this on production, what I've done to pass this right now, is have an mbean that on stop removes the tables from the database.

Why can't this be used as a cache? In a Hibernate fashion? Do we need to query every time the binding_template? How often does it change?

I work for a Red Hat partner in Brazil, we are on the process of "free to fee" with our customer, we solved the issue by cleaning the table, but I can't guarantee that after a few days running the problem comes back, I really believe it happens only on startup and stop.

Best regards

(and please, help us ;) )

> Possible Juddi Performance problems
> -----------------------------------
>
>                 Key: JBESB-1675
>                 URL: http://jira.jboss.com/jira/browse/JBESB-1675
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Registry and Repository
>    Affects Versions: 4.2.1
>            Reporter: Tom Cunningham
>         Assigned To: Tom Cunningham
>             Fix For: 4.4
>
>
> From forum post :
> We are not using juddi directly, I do not know if it is a core required component of ESB. After a few runs, we are having performance problems that seems to be related to juddi. It happens only on shutdow/startup operations. The time spent to create the auth tokens (sorry, what are they used for anyway??) are taking longer and longer. JBoss takes over 2 minutes (in a 8 processor machine??) just to delete the template bindings for juddi on the shutdown process. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira