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

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : The fix/work around we have is to stop step (8) from occuring.i.e. you never allow the thread pool to go below a minimum of one thread which avoids the race condition - there is always at least one thread available to execute the work. Ah, I understand. I intuited that this might be the case so I made the core thread pool size be implicitly at least 1, but I agree that this is undesirable overall. It would be nice if thread pools which are never used would never produce any threads. For my "blocking" policy, I'm not actually using a special rejection handler; instead I wrap the BlockingQueue with one that blocks on "offer". I still have to do some testing to see if that's a good approach, however I suspect it will not suffice to avoid this race condition even if it is a usable approach overall. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187382#4187382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187382

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by ataylor

Trustin, Ive made you're suggested changes and checked them into the branch. I'll catch you tomorrow and we can catch up and decide what to do next. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187378#4187378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187378

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-380; constructor (property) matching

by alesj

Carlo is complaining about how we match which constructor to use: - https://jira.jboss.org/jira/browse/JBMICROCONT-380 Thinking about it, what is really the reason we don't do better - more exact matching - in InstantiateAction? As constructor parameter dependencies should already be resolved, we could eventually pre-invoke that ValueMetaData's to get real parameter values, and do matching based on that? Same with other parametrized metadata - property, lifecycle, installs, ... I'm probably missing something obvious. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187376#4187376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187376

17 years, 5 months

1
0
0 / 0

[Design the WSRP implementation] - Re: WSRP (Jboss Portal & SharePoint Services)

by lgadams

Hello mleao, Have you worked on this configuration yet? I am trying to integrate jboss 2.6 and sharepoint currently. I am having some problems and I just wanted to know if you have tried this yet. I have been looking all over the internet from some examples and help on this topic, but no one seams willing to help on this. Please let me know if you have tried this yet. thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187357#4187357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187357

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by david.lloyd＠jboss.com

"alesj" wrote : Nice! | | But I guess you should provide some examples. | e.g. few xml snippets, explaining what does what OK, it's pretty straightforward. Basically if you have a pojo component that requires an executor, you can build it declaratively via XML (imagine a security manager scenario - by building your executor this way, your code needs no special thread-control permissions). So to create a thread pool for my application which keeps from 2 + 1.2n to 4 + 2n threads (where n = # of CPUs), with a bounded queue and a blocking reject-policy, I would just add a jboss-threads.xml file like this: <threads xmlns="urn:jboss:threads:1.0"> | <thread-group name="MyThreadGroup" group-name="my-app" daemon="false"/> | <thread-factory name="MyThreadFactory" group="MyThreadGroup"/> | <thread-pool-executor name="MyExecutor" thread-factory="MyThreadFactory"> | <core-pool-size count="2" per-cpu="1.2"/> | <max-pool-size count="4" per-cpu="2"/> | <bounded-queue size="50"/> | <reject-policy name="block"/> | </thread-pool-executor> | </threads> This makes an injectable bean called "MyExecutor" which I can add to my application using the normal mechanisms. Alternately I could "borrow" a thread pool executor declared elsewhere, with a hook so that it changes the thread's name when it's running one of my tasks: <threads> | <notating-executor name="MyExecutor" parent="SomeOtherExecutor" note="Running my task"/> | </threads> There are three different queue types available (bounded, unbounded, and direct), a variety of reject-policies, and pluggable interrupt and exception handlers. One thing I did not (yet) account for is a facility to propagate various thread context information to tasks (things like a context classloader, security context, transaction context, etc). I imagine some kind of pluggable system where a context type can be registered with code that knows how to get context from one thread and put context to a new thread. Then it's just a question of adding a plugin for each context type, and new services which keep a thread context could just be registered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187351#4187351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187351

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 4) Thread 1: Submit some work - pool is busy so wait | NOTE: Without this requirement in step 4 which isn't a policy available in java.util.concurrent you can't have the race condition. The submission of the work will either throw an error immediately, after a timeout or run the work on Thread 1 But for an MDB singleton none of those options are what we want. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187348#4187348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187348

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: NPE in TransactionScopedEntityManager

by alesj

"alesj" wrote : I see this duplicate MBean registration: Fixed. ;-) I changed how we name PUMD component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187347#4187347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187347

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : | "adrian(a)jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition) | | I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked. I'll have to look at that one more time... The issue comes with small thread pools. e.g. a singleton MDB configuration has a thread pool size of 1 Depending upon the reaping policy of unused threads it is possible for a race condition to go something like this (I'll assume no queue although it makes no real difference in practice since the race would still happen after dequeuing): 1) Thread 1: Submit work to the pool 2) Thread 2: Execute the work 3) Thread 2: Complete work 4) Thread 1: Submit some work - pool is busy so wait 5) Thread 2: Return thread to the pool 6) // CPU starvation for longer the idle time of threads 7) Thread 1: Stop waiting and check we have enough threads (we do) 8) Thread 2: I've been idle too long so end So you end up with thread 1 thinking there are enough threads to execute the work, but Thread 2 has stopped an instant after the check. The work will never be executed unless some other thread also tries to execute some work on the pool (meaning the number of threads gets rechecked). For a singleton MDB with a read-ahead of messages of size 1 this never occurs so message delivery to the MDB stalls. The fix/work around we have is to stop step (8) from occuring. i.e. you never allow the thread pool to go below a minimum of one thread which avoids the race condition - there is always at least one thread available to execute the work. The real fix would be to make the check in step (7) more atomic i.e. move the thread pool size check to later when it tries to execute the work but that's not easy to do if you look at the code. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187346#4187346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187346

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : Why are you using float for thread priority? | A thread can only take an integer priority between | 1 (Thread.MIN_PRIORiTY) and 10 (Thread.MAX_PRIORITY) I got the notion in my head that MAX_PRIORITY might not be 10, so my thought was to take a float between 1.0 and 10.0 inclusive and scale it between MIN and MAX. Though I guess I overthought it, since if someone decided to arbitrarily change the priority scale, there would probably be compatibility issues, so that would seem to be a rather unlikely scenario. "adrian(a)jboss.org" wrote : Even if it was a decimal, BigDecimal would be better than float because of the rounding errors. I doubt that someone would care if their thread at priority 10.1 was really running at 10.099999999999999644728632119950, since it would very likely end up being the same priority value anyway :-) In any case, making this a float was probably a dumb idea - I think I'll just make it an int. "adrian(a)jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition) I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked. I'll have to look at that one more time... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187342#4187342 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187342

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by adrian＠jboss.org

Looks good (but I only gave it a quick scan). Obviously it needs some tests to avoid regressions. :-) A few issues: * THREAD PRIORITY Why are you using float for thread priority? A thread can only take an integer priority between 1 (Thread.MIN_PRIORiTY) and 10 (Thread.MAX_PRIORITY) Even if it was a decimal, BigDecimal would be better than float because of the rounding errors. See for example the xsd:decimal bindings here: http://www.xyzws.com/scdjws/studyguide/jaxb_samples2.0.html or look at the jaxb spec for recommended bindings. * MBEANS You can inject into MBeans just like you can pojos * JBoss's BasicThreadPool and Task abstraction We already have an abstraction in the common-core project that adds to the basic thread pool executor abstraction. (Mostly by wrapping it). This adds things like lifecycle and error handling callbacks via the task abstraction, and management exposure via an MBean. But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187331#4187331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187331

17 years, 5 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 November 2008