[Design of JBossCache] - Service threads
by manik.surtani@jboss.com
This is in response to a few related JIRAs:
JBCACHE-1262
JBCACHE-1268
JBCACHE-1108
There are other internal service threads as well, such as async cache loader writer threads, repl queue threads, etc.
WRT. the JIRAs above, it makes sense to refactor these to use an ExecutorService and then allow users to pass in their own ExecutorService, either via an ExecutorServiceProvider interface, or by using a setter on the Configuration (for IOC frameworks). This would default to a fixed pool service using a single thread, except for the case of JBCACHE-1262 and JBCACHE-1108 where it may make sense to allow users to configure a pool size.
Now my question is this - how much flexibility would people want? Does it make sense to use a single ExecutorService for all such service tasks? Or does it make sense for this to be more fine-grained?
Brian, this would be related to your use case of not using the internal eviction thread for SFSB state.
Perhaps what we need is a decoupling between the executors themselves and the tasks they are used for - e.g.,
| <executors>
| <executor name="evictionExecutor">
| <pool size="1" />
| <async />
| </executor>
| <executor name="genericExecutor">
| <lookupClass>com.company.MyAppExecutorProvider</>
| </executor>
| </executors>
|
| ...
|
| <eviction>
| <executor name="evictionExecutor" />
| ...
| </eviction>
|
| ...
|
| <notifications>
| <executor name="genericExecutor" />
| </notifications>
|
| <replication>
| <async>
| <executor name="genericExecutor" />
| </async>
| ...
| </replication>
| ...
|
Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164568#4164568
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164568
17 years, 8 months
[Design of JBossCache] - Re: JBoss Cache Public API
by manik.surtani@jboss.com
Bringing this back up again.
"bstansberry(a)jboss.com" wrote :
| Depends on whether they require some cleanup beyond garbage collection. Sounds like that's the thing to investigate.
|
Consider a lot of the collections maintained by several components, like Notifiers, RegionManagers, etc. Usually these are uninitialized, are set on creation so that after creation, for example, regions and listeners can be created and added. Upon calling stop(), these are emptied, but the collections still exist so that more such elements could be added and the cache restarted. Destroy() on the other hand assigns the refs to these collections to null, so that the collections themselves can be gc()'d.
I guess the question to ask is how important is it to have these collections hanging around? Not a severe impact, I imagine, given that a ref to the cache still exists.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164560#4164560
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164560
17 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Sweet life on the journal...
by clebert.suconic@jboss.com
Life is being good here... :-)
I'm doing some changes on the journal, what will supposedly make Recovery rock solid to failures, and what will avoid us from filling the file when we reuse a file, what will bring us the performance we wanted.
Every record will look similar to this layout:
Byte - recordType
Integer - journalSequenceID (the sequence ID used by the current journal)
Integer - variableSizeLength (used on Add/Updates only)
.... Body of the Record ....
Integer - checkSize (Number of bytes written at this record).
The journalSequenceID is to make sure the record is not garbage from the previous file usage. This would avoid us from refilling the file. I have also make that a sequence and an integer (I wanted to save 4 bytes on every record).
The checkSize is to make sure the record is complete. ON tests I have seen situations where the variableSizeLength got damaged what was making recovery impossible.
I'm also changing how the load is being done. On the event of any damage.. I just skip that record and keep going until I can find the next valid record on the file. I'm also adding some logic to throw away uncomplete transactions.
The numbers I'm getting are really impressive. As I don't need to fill the journals, I'm being able to perform 22K records / second on perfListener/perfSender (PERSISTENT). And the number of files never goes beyond 10.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164540#4164540
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164540
17 years, 8 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by jhalliday
Now that AS trunk uses JBossTS 4.4.0.CR1, the transaction maanger side of the XAResourceRecoveryRegistry is available. The JCA now probably needs updating to register suitable XAResource(s) for any datasources.
Here is a trivial usage example to get you started:
| import org.jboss.tm.XAResourceRecovery;
| import javax.transaction.xa.XAResource;
|
| public class TestASXAResourceRecovery implements XAResourceRecovery
| {
| public XAResource[] getXAResources()
| {
| System.out.println("you should see this on every recovery pass i.e. every two minutes");
| return new XAResource[0];
| }
| }
|
deploy/test-beans.xml:
| <?xml version="1.0" encoding="UTF-8"?>
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <bean name="MyConnectionManager" class="TestASXAResourceRecovery">
| <install bean="TransactionManager" method="addXAResourceRecovery">
| <parameter><this/></parameter>
| </install>
| <uninstall bean="TransactionManager" method="removeXAResourceRecovery">
| <parameter><this/></parameter>
| </uninstall>
| </bean>
|
| </deployment>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164511#4164511
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164511
17 years, 8 months