July 2008 - jboss-dev-forums - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by jhalliday

Also any reason why it's in the JCA SPI rather than the transactions SPI? XAResource is a transaction thing, not a JCA specific thing. What happens when some non-JCA POJO component wants to use it? JBoss cache may be an example - it's not a JCA connector as far as I know. It makes no odds to me, since JBossTS won't have a compile time dependency on it anyhow, I'm just curious. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164523#4164523 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164523

17 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by jhalliday

"jesper.pedersen" wrote : Jonathan, I've added the following interface to the JCA SPI in jboss-integration: | | org.jboss.jca.spi.xa.XAResourceWrapper | | with the methods getEISProductName() and getEISProductVersion(). So you can depend on this interface for AS-5.0. | Thanks. When is that actually going into AS 5.0 trunk? I can build the integration module trunk and drop it into the AS by hand, but it's a bit of a pain for testing against. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164521#4164521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164521

17 years, 8 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of the JBoss EJB Container] - JBOSS - Oracle DB Connectivity Issue.

by etrans

We are using JBOSS version 4.0.5GA and Oracle 10g version 10.2.0.4. During the day the database process in the OS increases. In the application all open connections are closed appropriately. The connection string are written in the JSP pages and java processes. Does JBOSS control or close open connections ? Or is it possible that Jboss is unable to close the database connection/session. As the open connection increases and the Databse and the system becomes slow, forcing us to restart the DB. Any Solution, Thanks in advance. Regards, SK View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164468#4164468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164468

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Defining the API Mission

by thomas.diesler＠jboss.com

Folks, I put together a mission page for the API. Please have a look at http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIMission cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164408#4164408 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164408

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - PVM repository relocated again

by heiko.braun＠jboss.com

The (final) repo can be found here: https://svn.jboss.org/repos/jbpm/jbpm4/pvm/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164396#4164396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164396

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] EJB mappedName as a Base?

by ALRubinger

For now I've deprecated the "determine" logic from the Object Model (see JBMETA-68) but EJB2.x still relies on these methods. So the new EjbMetadataJndiPolicyDecoratorDeployer will decorate EJB3 deployments only with a JNDI Binding Policy. So adding new JNDI Policies later should be a natural progression towards providing an EL-based implementation. The hitch here is that jboss-metadata tests are not for EJB2, and these are not backwards-compatible (because they're not wrapped ie. getJndiName uses the old logic). So MappedReferenceMetadataResolverDeployer must still reference the @Deprecated methods I'd like to remove. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164385#4164385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164385

17 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2008