June 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - SessionFactories being garbage collected

by timfox

I've noticed a *lot* of this, especially in the client integration tests: | protected void setUp() throws Exception | { | super.setUp(); | | ... | | ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration(InVMConnectorFactory.class.getName())); | | .. | | session = sf.createSession(false, true, true); | session.createQueue(address, queue, false); | | } | The sf variable is local to the method, so when the method completes it is liable to be garbage collected, but the session is still being used. This can cause all sorts of problems. You *cannot* let the sf be garbage collected until you're finished with the session. This kind of thing is just asking for problems. Now, I need to go and change about 200 tests... :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235642#4235642 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235642

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: CoreClientOverHTTPTest is commented out

by jmesnil

it was commented in http://fisheye.jboss.org/changelog/Messaging/?cs=5967. I don't know why. I'll uncomment it.[/url] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235620#4235620 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235620

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: WARN message in InterceptorsFactory

by wolfc

No, it really means what it says. The construct should not be used, it does nothing anyway. :-) So try to remove that construct from core and test for regression. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235608#4235608 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235608

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Excluded JMS Tests

by timfox

Why are the following excluded: ? | <exclude name="**/jms/XARecoveryTest.class"/> | <exclude name="**/jms/XAResourceRecoveryTest.class"/> | <exclude name="**/jms/XATest.class"/> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235605#4235605 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235605

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: CoreClientOverHTTPTest is commented out

by timfox

No-one? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235603#4235603 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235603

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - AIO documentation

by timfox

| The size of the timed buffer on AIO. The default value is 128MiB. | Really? ;) Also, there's not mention on tuning the timeout or buffer size, and there's no explanation on what any of these things do :( Also | If this is set to true, the internal buffers are flushed right away when a transaction arrives. | JBoss Messaging was made to scale up to hundreds of producers. We try to use most of the hardware resources by scheduling multiple writes and scheduling multiple writes in a single OS call. | However in some use cases it may be better to not wait any data and just flush and write to the OS right away. For example if you have a single producer writing small transactions. On this case it would be better to aways flush-on-sync. | Is not true. This is nothing to do with transactions, flush on sync is also used in non transactional situations, depending on the sync settings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235579#4235579 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235579

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: WARN message in InterceptorsFactory

by jaikiran

"jaikiran" wrote : | | Any reason why we should not remove this InterceptorsFactory from ejb3-interceptors-aop.xml AOP advices? | | Should have read EJBTHREE-1246, before asking this :) The comments there say: anonymous wrote : | The ejb3-interceptors can run in multiple modes, two of which are AOP weaved interception (basic) and Container managed interception (direct, proxy and indirect). For EJB lifecycle callbacks to be properly handled in 'basic' mode InterceptorsFactory and InjectInterceptorsFactory are used. Both of which do nothing if used in 'container' mode and will give out a warning as such. In my opinion, it should not be a WARN message then. Probably a DEBUG would be right. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235574#4235574 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235574

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - WARN message in InterceptorsFactory

by jaikiran

I was looking at https://jira.jboss.org/jira/browse/EJBTHREE-1841 and other similar user complaints about the following WARN log message on first access to a bean: 09:02:34,655 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container | Looking at the InterceptorsFactory class, which gets called as follows: 1) Client calls bean method for first time 2) The call is passed through AOP interceptor chain 3) AOP starts initializing any per instance advices (InterceptorsFactory is one such advice) 4) We issue a WARN and return a NoOpInterceptor >From what i see in the InterceptorsFactory, its probably no longer required since the same functionality is now done through the InjectInterceptorsFactory and InterceptorRegistry. Any reason why we should not remove this InterceptorsFactory from ejb3-interceptors-aop.xml AOP advices? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235572#4235572 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235572

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: nanoSleep

by timfox

"clebert.suconic(a)jboss.com" wrote : The minimal resolution I have found on Rhel is 1 millisecond. No matter what you do. (No wonder Java has decided to not implement System.sleep for micro and nanosleep yet). That's a mess when you consider multiple platform even among different kernel versions. Clebert, this does not make sense. Earlier in this thread you posted results that showed 1000000 nanosleeps taking in total 17, 3856 milliseconds, which is way less than 1 ms, so your statement is completely contradictory to your results. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235570#4235570 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235570

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - EJBTHREE-1844: Retry on rollback

by wolfc

I've added a function to retry an operation whenever an EJBTransactionRolledbackException occurs. Usually this is because of a resource commit failure, which could be caused by a temporary problem (dead lock / outage). To configure the retry currently the annotation org.jboss.ejb3.tx.api.TransactionRetry needs to be put either on the bean or on a method. What I don't like is the fact that the annotation now resides within ejb3-transactions, so I've marked it experimental. Either it should go to ejb3-ext-api, but this would change our api (for the better) or into ejb3-tx-api. Alternatively I could create an ejb3-tx-retry component which would could slot into a runtime. Also we need to be able to extend jboss-metadata to allow plugins, so that the retry function can be enabled via descriptors. How do we want to proceed here? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235567#4235567 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235567

16 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009