|
From: Steven H. <sh...@te...> - 2005-06-21 23:52:22
|
Okay, I didn't want to go into too much detail in my initial post because I was just hoping to feel out if anybody else had had this experience. My gut feel this is a 'hard' problem, and unless it was a known issue, I could be in for some very hard diagnosis in house. For what its worth, we run Oracle 9i Enterprise Edition as our database server Attached are the load graphs for the machine, as you can see, in the last three weeks, things have been kind of quiet, we moved a major (non hermes) related application off the box a few weeks back. The problem occurred during the 'quiet' period. Our operations team assures me nothing was running at that time, and besides, we've never had an incident of delayed queries during database maintenance activities - one of the benefits of Oracle I guess. If there is any information or documentation about the inner workings of Hermes that could be contributed, or any similar experiences that could be shared, that's all I'm really hoping for. Kind Regards Steven Herod -----Original Message----- From: ebx...@li... [mailto:ebx...@li...] On Behalf Of R. van Kuijk (Ronald) Sent: Tuesday, 21 June 2005 2:22 AM To: ebx...@li... Subject: RE: [ebxmlms-general] Again, unreliable execution of message handlers. What db is used? Hsqldb processes all requests sequential, so an export of a db with a large number of records can hold things up quite easily. Ronald -----Oorspronkelijk bericht----- Van: ebx...@li... [mailto:ebx...@li...] Namens David Webber (XML) Verzonden: maandag 20 juni 2005 16:48 Aan: ebx...@li... Onderwerp: Re: [ebxmlms-general] Again, unreliable execution of message handlers. On the serious side - yes - I was thinking the same thing - that maybe some housekeeping / compaction service in the DB server occurred that took ten minutes to complete. DW ----- Original Message ----- From: "Mattias J" <mj...@ex...> To: <ebx...@li...> Sent: Monday, June 20, 2005 10:01 AM Subject: Re: [ebxmlms-general] Again, unreliable execution of message handlers. > Maybe also the RDBMS in use may be relevant? > > At 2005-06-20 15:37, you wrote: > >Steven, > >How many records are there in the database? In particular, how many > >records in mshconfig table? in messagestore table? I am still not sure > >about the reason, just wondering whether the number of records in database > >is one of the factors determining speed or not.. > >Regards, -Patrick > > > > > >Steven Herod wrote: > > > >>About a week ago, we had another incident of message handler not executing > >>on message arrival. > >> > >>In this case however, it wasn't a complete failure, instead, it seemed to > >>take about 10 minutes between hermes receiving the file and the message > >>handler picking it up. > >> > >>Normal behaviour has this occuring within a few seconds, however, in this > >>case, about 10 minute passed before the handler fired. Our messages are > >>time sensitive, so this pushed the response time window outside of normal > >>and raised an error with our customer. > >> > >>There are no log files indications of a reason for a delay, the message > >>handler usually fires off within a few seconds of the message arriving. > >> > >>I realise this is a little vague, but I'm wondering if anybody else has had > >>this experience or observed this behaviour? > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ebxmlms-general mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-general > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |