[Design of Messaging on JBoss (Messaging/JBoss)] - MaxIO, MinFiles and JournalFileSize
by clebert.suconic@jboss.com
When you initialize libaio, you also initialize the number of AIO positions you will have on the kernel. That is the maximum number of pending you writes you could have on the kernel. There is an almost hard limit on the OS, I guess it's 25K (I say almost.. because the variable it's not documented, or if it is.. it's hard to find it).
After few tests I have done, I've been able to get very good numbers, using the StoreManager directly. But the best number I could get to my disk was 10000. With that we can't have more than 2 files opened with AIO. Since the journal is append only, I guess it would be okay to make it a little bigger, since we won't make any reads on the file.
I will make the MaxIO configurable on the Configuration, but IMO the default for min files should be 2, and the size of each journal at 100M.
Putting the file at 100M would minimize the number of closes/opens you would do in production also.
When you close a file in AIO, you need to wait all the pending writes to complete before you can actually close it and move to the next file.
(Maybe I should use an executor to close the file to avoid the eventual latency, but if you could minimize the number of closes on AIO it would still a good practice IMO)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150454#4150454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150454
17 years, 11 months
[Design of JCA on JBoss] - Re: JBAS-3632
by adrian@jboss.org
I don't understand your question/comment.
If it is "how do I reproduce it?" then you need to set up some ejb calls that does
something like the following.
1) Start a transaction, e.g. invoke a CMT/Required ejb method
2) Make an ejb invocation on a different bean that opens a connection handle
but doesn't close it (e.g. like the thread local connection tests in the testsuite)
3) Force the transaction to timeout
Previously we would wait until the transaction ends when the method in step (1)
returns before checking for unclosed connections. This allows something
to close the connection that was "cached".
But since jboss-4.2.x the transaction timeout does the rollback which can
will give a spurious warning in this case.
NOTE: This usage is an anti-pattern and doesn't cause any real problems
which is why I'm not really too worried about this issue.
How it gets fixed is a different issue. It's tied up with the other JIRA issue
about the CachedConnectionManager rewrite that is required such
that it better understands the ejb lifecycle(s) and the "Debug" feature
needs redoing so it isn't so contentious on the WeakHashMap.
Search for other forum threads and links from the JIRA issues
for more information and ideas.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150440#4150440
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150440
17 years, 11 months