[Design of Messaging on JBoss (Messaging/JBoss)] - effect of irregular configuration of Thread Pool Configurati
by dhindu
hi,
we are using the jboss 4.0.4AS and jbossMQ for the JMS in our application. now we have a problem that it takes 4 to 6 secs to post a message in the particular Queue.
Since our application has JMS postings across 2, 3 modules all of them are slow. when we looked at the difference, we found the mbean tag in the jbossmq-service.xml in the ../../deploy/jms directory. we tried searching the effect of over or under configuring the values for the mbean tag for the JMS Thread Pool.
i have copy pasted the mbean tag below. We think this is the default configuration as we didnt change anything.
<!-- A Thread pool service -->
JMSThread
JBossMQ Server Threads
<!-- The max number of threads in the pool -->
10
<!-- The max number of tasks before the queue is full -->
1000
<!-- The behavior of the pool when a task is added and the queue is full.
abort - a RuntimeException is thrown
run - the calling thread executes the task
wait - the calling thread blocks until the queue has room
discard - the task is silently discarded without being run
discardOldest - check to see if a task is about to complete and enque
the new task if possible, else run the task in the calling thread
-->
run
My questions are
1. What are the effects if we over or under configure the thread pool limit and the queue depth?
2. What would be the default values if we remove the tags?
Thanks in advance,
Dhinesh Kumar P
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991077#3991077
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991077
18 years, 1 month
[Design of JBoss jBPM] - Re: SEAM / Java 5
by brittm
Tom,
Some random thoughts...
It's only my opinion, but I think Java 1.5 and SEAM are important for the project. From a marketing perspective, it says, "We're on board and part of a unified technological front--Jboss is/is going to be the leading JEE5 solution provider, and we're a major part of all the inovation that brings."
If a company, large or small, is going to adopt jBPM, they're doing it because they're ready to do something new--and a Java 1.5 requirement isn't likely to stop them.
Working for a big company, I know that we'll choose a solution based on its own merits, regardless of which JVM it runs on (within reason). If we choose the latest jBPM, we're running it on its own system, and on that system we'll run whatever is required. --we just enjoy working with 1.5 better, so we do :)
Looking at web technologies, its been our experience that JSF, on its own, is a royal pain--so we're moving our task management web app to Facelets (and perhaps SEAM) looking for better productivity. If we can't find it, we're likely to have to revert back to straight JSPs or be forced to a non-Java technology. That is just to say, that it's hard to go wrong by bringing in strategies that increase productivity and maintainability.
Also, when you find a group of programmers who are excited about a technology (like Gavin is about SEAM) it can be a lot easier to find someone willing to help work through sticky problems.
-Britt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991063#3991063
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991063
18 years, 1 month
[Design of JBoss jBPM] - SEAM / Java 5
by tom.baeyens＠jboss.com
I want to reopen the discussion on SEAM and Java 5. Afaik, the only reason, we didn't opt for SEAM was Java 5. But i can't seem to find that discussion thread any more :-(
Now we have a company that is considering collaboration with significant contributions. But they have seam as a prerequisite. If not SEAM, they are going to build /are already building their own web console with SEAM.
Since this is a matter of time, I think we might reconsider.
>From a general jbpm-adoption standpoint i don't think that dropping support for java 1.4 is a problem. BUT the problem is that big coorporations tend to be slow on adopting new versions... These might not be big in numbers, but they are important for JBoss. BUT Fadar also made the remark: 'if they are slow to adopt java versions, they will probably also be slow to adopt new jBPM versions...'
Note that this is only a compatibility issue for the web console. The runtime engine for 3.x versions of jBPM will surely remain 1.4 compliant. But this will of course also impact the java 5 compatibility requirement of the simple-to-install suite package and might give the wrong impression.
Anyways, these are all the pro and con arguments that i could think of from the top of my head.
Do you see other arguments ?
Would you think it is a good overall idea to move to SEAM ?
I know that Gavin is going to be happy if we would make the change... well... let's say he's going to declare us "less nuts" :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991044#3991044
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991044
18 years, 1 month
[Design of EJB 3.0] - Re: ejb3x mavenized
by bill.burke＠jboss.com
I've run into problems with the "mavenization" of the jbossas project. Over the past few months, EJB3 code just breaks without any changes to our codebase. You go to debug these problems and you find the module in question is party of repository.jboss.com and usually no access to the source that built that binary. This leads me to checking out that module and hoping and praying the HEAD of that submodule is in synch with the binary (many times it isn't). IIRC, JBoss 2.0 used to be broken out in much the same way that we're moving to now. We had many of the same problems and, in JBoss 3.0 decided to move to a build system that built every subproject together into one checkout.
A project like EJB3 sees these problems more often than other projects because EJB, at its core, is an integration project of many different technologies within JBoss. BTW, this is one of the reasons why I want to leave the EJB project. I'm sick of other projects breaking my code and me having to clean up after them.
IMO, if we're going to mavenize every JBoss project and break it up into its own build and its binary stuffed into repository.jboss.com, we need to start getting much stricter on what we allow to be checked into head. If you're going to rev jbossas/build-thirdparty for your project, you should be required to test any modules that are dependent on your project. The problem with this, is that nobody does a good job of keeping their junit tests passing. Since there is no good baseline to measure against, any rule of this type would make it very difficult to determine if your thirdparty checkin to repository.jboss.com causes any new instability.
What we really need to get to is a HEAD where all unit tests pass. If somebody checks in anything anywhere that causes a testsuite regression then HEAD should be frozen from *ALL* commits unti:
a) The eroneous commit is rolled back
b) the culprit fixes any problems.
IMO, we're just too big right now to allow the current development process to proceed as it is going.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991033#3991033
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991033
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Breaking up the MC project and Mavenizing it
by adrian＠jboss.org
"alesj" wrote : "scott.stark(a)jboss.org" wrote :
| | Every project should be further broken up into an spi/api artifacts for the spi packages, and a plugin artifact for the plugin/implementation packages.
| |
|
| Divided into different projects - [project]-spi and [project]-impl?
| Probably not?
|
Yes, that *is* what we want.
We need a project that creates a kind of "j2ee.jar" for our shared integration
such that people compile against the api/spi not the implementation details
which are subject to change and will only lead to incompatibilies if people did it.
There's also a case for creating seperate projects for
[project]-tests
since many of the tests do depend upon implemenation details (specific implementations)
that the main projects should not depend upon.
But, Maven does support classpaths for the main source and tests
(unlike Eclipse), so this is less important.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990979#3990979
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990979
18 years, 1 month