-
1. Re: LinkedList Factor on the Journal...
clebert.suconic Jul 30, 2008 11:31 AM (in response to clebert.suconic)Few solutions I have thought for this:
I - Separate CurrentFile by Destination type.
We would add/delete records per destination.
We would still be able to commit without a problem
I have written this code already, and it has one side effect. If the customer has 1000 lazy destinations you will have 1000 opened files, what is not possible on AIO.
II - Separate CurrentFile by Destination speed.
We could have a destination configured as Lazy, what would keep records in separate.
We would still be able to commit without a problem, as any commit record aways carries the filesIds and number of elements used.
This would use the code I already wrote on (i).
III - Depending on the number of dependencies found on Reclaiming, we could start a FullReclaiming logic (think of a fullGC) that would move records around, facilitating how the files are reclaiming.
This has performance implications. It's listed here just as a brain storm.
I think option II would be a reasonable one. -
2. Re: LinkedList Factor on the Journal...
timfox Jul 30, 2008 11:36 AM (in response to clebert.suconic)Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed.
Although I'm not convinced this is a major problem, more of an edge case.
In later JBM versions, we should probably remedy this by adding compacting to files to. -
3. Re: LinkedList Factor on the Journal...
gozilla Jul 30, 2008 12:05 PM (in response to clebert.suconic)Tim,
Sadly enough, this is not an edge case: when you have a decently sized messaging server, you have easily thousands of destinations used by hundreds of apps.
We had cases that apps used our MQ server to talk to some batch jobs, which were only triggered once a day.
Cheers,
François -
4. Re: LinkedList Factor on the Journal...
timfox Jul 30, 2008 12:19 PM (in response to clebert.suconic)I don't understand your point, we can support many hundreds and thousands of destinations.
-
5. Re: LinkedList Factor on the Journal...
clebert.suconic Jul 30, 2008 12:37 PM (in response to clebert.suconic)"gozilla" wrote:
Tim,
Sadly enough, this is not an edge case: when you have a decently sized messaging server, you have easily thousands of destinations used by hundreds of apps.
We had cases that apps used our MQ server to talk to some batch jobs, which were only triggered once a day.
Cheers,
François
Francois (user gozilla),
The case of many files would be a side effect of one of my suggestions to fix the problem, which I used as an argument to suggest II. That's not a real problem.
We already support many destinations without any problem. -
6. Re: LinkedList Factor on the Journal...
gozilla Jul 30, 2008 1:45 PM (in response to clebert.suconic)"timfox" wrote:
Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed.
Although I'm not convinced this is a major problem, more of an edge case.
My point was that having message hanging around in destinations for "long" time is happening frequently with a sized installation.
Francois -
7. Re: LinkedList Factor on the Journal...
clebert.suconic Jul 30, 2008 2:00 PM (in response to clebert.suconic)"gozilla" wrote:
"timfox" wrote:
Yes this is a known issue. If you have messages hanging around in a destination for a long time, then sure, they'll stop the file from being reclaimed.
Although I'm not convinced this is a major problem, more of an edge case.
My point was that having message hanging around in destinations for "long" time is happening frequently with a sized installation.
Francois
I added a patch with a proposed fix on
https://jira.jboss.org/jira/browse/JBMESSAGING-1342
We should do it before Beta.
Just the fact of having Messages on DLQ for instance would break reclaiming at the moment. So I think it is a major issue.