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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bounding the number of threads created by the MDB contai

by ovidiu.feodorov＠jboss.com

That's the whole point, you don't need a thousand threads to get order guarantees. This simply doesn't scale, as I've recently seen in a couple of cases in production. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156838#4156838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156838

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by scott.stark＠jboss.org

Well, I'll see if I can get f9 installed on a box here to see if I can reproduce it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156837#4156837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156837

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bounding the number of threads created by the MDB contai

by timfox

I don't really see how a pooling approach will work. Each session requires an executor so it can ensure that deliveries (etc) for that session are executed on a different thread but in the correct order. If you got a thread from the pool each time to execute the delivery then you couldn't guarantee that order any more, since you won't guarantee it's the same thread being used. What might work is pooling executors rather than threads, but then you could get into deadlock situations where one session is waiting on getting an executor but can't complete because the executor pool is full and the system will just hang. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156834#4156834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156834

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by anil.saldhana＠jboss.com

Scott, this is an hindrance to development on F9 at the moment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156833#4156833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156833

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Bounding the number of threads created by the MDB container

by ovidiu.feodorov＠jboss.com

Each MDB container deployment that uses the standard JBoss JMS JCA adapter creates a pool of 15 (default number, but configurable) server sessions, and each such server session starts by default at least 2 new threads (the executors of the server side session endpoint and the client side session delegate). That is 30 JBM threads per MDB deployment. Each MDB deployment can be tuned to reduce its number of server sessions, but a little more elegant solution would be to allow JBM to accept a thread pool for all its primitives to use. This is the spirit of http://jira.jboss.com/jira/browse/JBMESSAGING-1356. This way, an instance administrator can put a upper bound to the total number of threads used by MDBs within an instance, regardless of an MDB individual configuration. Generalizing, if one wants to limit the maximum number of threads used by JBM within a VM, should be able to configure all thread-related JBM primitives to use a central thread pool. I'll take a stab at implementing this. What branch should I apply my patch on? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156830#4156830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156830

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - @InstanceAnnotation

by kabir.khan＠jboss.com

As mentioned here: http://www.jboss.com/index.html?module=bb&op=viewforum&f=204 and http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141090#4141090 I did not like the use of @InstanceAnnotation to dictate the behaviour of the proxyfactory. What I have done locally is to make AOPConstructorJoinPoint stop doing the check, and to pass in all per instance metadata to the proxy factory. The check inside the proxy factory used to be blindly to create a proxy if there is metadata present. The new check checks if there is instance metadata present, and if so checks if the resulting instance advisor has more aspects than the class advisor. If there is, then we return a proxy. If the instance metadata does not mean any more bindings or interface introductions are matched, then we return the original object. This is all sitting locally on my machine. I had to make a few minor changes to the aop-mc-int tests to to get this working. The main thing not workin is the HasInstanceAnnotationTestCase which I think should be retired. This is all ready to commit unless anybody has some objections? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156815#4156815 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156815

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: failure of MessageConsumerTest.testRedelMessageListener2

by timfox

This should be fixed now. This means we should get a clear run apart from one AIO test that Clebert is looking into. >From now, the test suite should stay at green. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156811#4156811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156811

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by scott.stark＠jboss.org

The server has been running for a couple of hours now with no increase in file descriptors or ports. I suspect its the "Too many open files" causing the issues. What are the ulimits your running under? If you have an lsof output you can send it to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156798#4156798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156798

17 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - portal clustering problem whne using optimistic locking and

by prabhat.jha＠jboss.com

The problem is described at JBPORTAL-1879 and I have narrowed down it to configuration where this problem can be easily replicated. It only happens when optimistic locking used with REPL_SYNC as cache_mode. <attribute name="NodeLockingScheme">OPTIMISTIC</attribute> | <attribute name="IsolationLevel">REPEATABLE_READ</attribute> | <attribute name="CacheMode">REPL_SYNC</attribute> | Changing CacheMode to REPL_ASYNC or LOCAL as well as using Pessimistic locking does not result into this problem. I think we need to look into following possibilities besides looking into portal code base 1. Problem with org.hibernate.cache.OptimisticTreeCache or the way we are using it 2. Deadlock in org.jboss.cache.lock.ReadWriteLockWithUpgrade View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156792#4156792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156792

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by manik.surtani＠jboss.com

"genman" wrote : | The problem with "putAll" (and "put" and "remove") is that they require a storage read for every call. If you can get them to perform okay, then I don't really care. | Why? I agree that such calls should be optimised by the Interceptors not to do a load if the state needed is already in mem (for the return value of a put or remove), but beyond that, why would putAll, etc. do a storage read? "genman" wrote : | "manik.surtani(a)jboss.com" wrote : | | Something like this already exists - JBCACHE-1082. Needs to be worked in to the codebase, properly profiled and optimised though. | | It'd be nice if there was a canonical key object though. Something that could be optimally serialized and deserialized as a single byte using the existing CacheMarshaller. Maybe like have something like: | | | | public interface Node { | | | | private enum Key { KEY; } | | | | /** For nodes that store a single value, use this as the key */ | | Object key = KEY; | | | | ... node methods here | | } | | | | "enum" is good for creating singleton instances. Yup. Good thoughts to add to the relevant JIRA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156790#4156790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156790

17 years, 10 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 June 2008