Re: [jboss-user] [Beginner's Corner] - problems with an EAR file with MDBs
by null null
null null [http://community.jboss.org/people/ranjix] replied to the discussion
"problems with an EAR file with MDBs"
To view the discussion, visit: http://community.jboss.org/message/546272#546272
--------------------------------------------------------------
thanks Jaikiran.
I did one better, I started debugging the servlet with Eclipse. The good part is that is obvious that it does indeed execute the servlet. The bad part is that is obvious that JBoss uses same classloader for all the EARs, at least in this case (because when I don't have the MDB it doesn't), which makes the servlet (which uses some statics) to believe that the new starting "app" is already initialized.
In any case, I set the isolation of the EARs as true (ear-deployer-jboss-beans.xml, "isolated" property as true), and now it looks better, but I'm debugging a conflict between some Xerces libs in our app vs. the ones in JBoss. I'll need to play more with the isolation, the final goal is to have one classloader per EAR, which will be used by all the WAR and EJB-JARs inside.
Hmm... It looks like the following worked -
<jboss-app>
<loader-repository>
publish:archive=publish.ear
<loader-repository-config>
java2ParentDelegation=true
</loader-repository-config>
</loader-repository>
</jboss-app>
Anyway, thanks. Home my issue is fixed at this point,
ranjix
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546272#546272]
Start a new discussion in Beginner's Corner at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Tools] - How Developers should use JBoss Tools JIRA
by Max Andersen
Max Andersen [http://community.jboss.org/people/max.andersen%40jboss.com] modified the document:
"How Developers should use JBoss Tools JIRA "
To view the document, visit: http://community.jboss.org/docs/DOC-12834
--------------------------------------------------------------
JBoss Tools jira is located at https://jira.jboss.org/jira/browse/JBIDE https://jira.jboss.org/jira/browse/JBIDE and its related project JBoss Developer Studio has a jira at https://jira.jboss.org/jira/browse/JBDS https://jira.jboss.org/jira/browse/JBDS
h1. Lifecycle of an issue
Overall the lifecycle of an issue that is supposed to be implemented (i.e. not rejected) the lifecycle is as follows:
1. Someone creates an issue
2. if it is a relevant issue a committer assigns it for a fix version
3. a committer fixes the issue and resolves the issue
4. during QA the issue gets 1. Closed or
2. Reopened if the issue is not fully resolved and then Goto #3
h2. Creation
Anyone can create an issue. When the issue is created it should as a minimum have:
* a *good summary* (selfexplanatory if possible)
* a *Component* to make it show up categorized instead of in the https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hi... "No Component" component which would make it hard to see which components has the most need for attention/workload. If you feel there is no matching component go to the devel list and suggest one.
* *Affects version* so we know which version to reproduce the issue in
* *Description* to allow us to reproduce the issue or understand what the feature is about. Attach projects, output from Help > Report problem, screenshots or even a http://www.jingproject.com/ screencast to illustrate what you want to describe.
Assignment should not happen before you know for sure the committer is going to work on the issue.
h2. Assignment
Only committers/developers should assign the issue. Do not assign the issue to anyone unless that is yourself or you know for sure he or she is supposed to work on it. If all issues are assigned we cannot see which are unassigned and needs attention.
The one who is assigned should also make sure to set:
* the *Fix Version(s)* to indicate when it should be completed, without a Fix Version it will not show up in the https://jira.jboss.org/jira/browse/JBIDE?report=com.atlassian.jira.plugin... Road Map nor https://jira.jboss.org/jira/browse/JBIDE?report=com.atlassian.jira.plugin... Change log
* the *Priority* should be set in context of the Fix Version, i.e. an issue can be trivial to implement but still be a Blocker if it is a must have feature or bug to have for the release.
h4. Automatic Assignment to component lead
Since April 1, 2010 we changed the default assignment from "Unassigned" to "Component Lead" meaning component lead's will get notification immidiatly for incoming issues and they should make sure the jira gets processed.
If the issue is not yours, reassign to the right component/assignee.
If not something that will be done by you, make the issue "Unassigned" and set proper fix version.
Rememeber that to get automatic assigment for component lead on already assigned issues choose "Automatic" in the Assignment field.
h2. Discussions
*Keep description updated* - which means if issue has a discussion what actually should be done all this should be collected in description. That saves time for anyone who is working with this issue to understand what actually should be done and how to verify it. Last thing is useful for QA.
h2. Fixing/Resolving
When an issue gets fixed the developer should make sure to:
* *Add unittests*, any non-trival issue is not fixed and should not be committed before the unittest is there for it
* *List the JIRA URL* in the relevant commit(s) (e.g. https://jira.jboss.org/jira/browse/JBIDE-42 https://jira.jboss.org/jira/browse/JBIDE-42 ) together with a short comment on what was done
* *Resolve* (not Close) the issue and *do not reassign it to QA* engineer to let track your progress on issues
* *Comment* on what was done, i.e. sometimes "Done" is fine but if something were done differently than initially discussed in the jira or one of multiple options were implemented state which one and if some new api/feature was introduced put an explanation on how to use it.
* *Write Test Cases/Scenarious* for QA and users with EXECUTE/ASSERT statements describing what should be tested manually to verify the testcase or *attach relevant screenshots* or *create screencast* to show new functionality.
* *Verify the Component and Fix Version* is correct, remember that if we have branched for doing a release and you fixed the issue in both branches set both related versions (i.e. 3.0.0.beta1 and 3.0.0.cr1), if you only fixed it in one branch/trunk make sure you select the correct version. Be aware that an issue should not be closed if it points to a .x release, i.e. 3.1.x signals things to be done in the 3.1.x stream - an issue should target a or multiple *specific* issues when closed, i.e. 3.1.1 and 3.2.M1.
h2. QA/Closing/Reopen
During QA a committer or QA engineer verifies the issue following the description and/or EXECUTE/ASSERT instructions and if the issue is completed he should:
* *Verify the Component and Fix Version* is correct
* *Close* the issue
* *Comment* with which build/setup he verified it in
If the issue is not completed then
* *Reopen* the issue
* *Comment* what is not working
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-12834]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years
[JBoss Messaging] - MDBs using RemoteJMSProvider seem to stop under large number of MDBs
by Mike Miller
Mike Miller [http://community.jboss.org/people/mikemil] created the discussion
"MDBs using RemoteJMSProvider seem to stop under large number of MDBs"
To view the discussion, visit: http://community.jboss.org/message/546247#546247
--------------------------------------------------------------
Hi,
We are in the process of migrating from JBoss MQ over to JBoss Messaging, running on 4.2.3 GA. We are using the jboss-remoting.jar from 2.2.3. A little background, we have a Central server and many Store servers. We create transactions on the Store servers, which then save to our database and then put the transaction data on a local store queue. On our Central server, we have a set of MDBs using a Remote JMS Provider definition to actually pull the transaction data out of the queue (mdb) and save it to our Central server. We have about 400 stores running and our Central server. For the most part, we are using the base configuration from the JBoss documentation, with the exception that we are in a firewall configuration so in the remoting configuration, we are setting the secondaryBindPort and secondaryControlPort values to the same value, 27900 - based on some previous forum responses from Ron Sigal in the Remoting forums.
Our Central server deploys 400 MDBs, one pointed at each store server to pull transaction data from the Store servers. Once the Central server gets started successfully we intermittently encounter problems where transaction stops being delivered to our MDBs running on Central. This problem does not happen with lower numbers of Store servers, like 200.
We have noticed thru using JConsole that for each MDB pointing at a store, we are getting 4-5 threads created for each store:
1) Connection Consumer for dest JBossQueue(mdb name here)
2) control:Socket[addr=store1/ipaddr of store1, port=27900, localport=xyz...] --> appears only when store connected
3) control:Socket[addr=store1/ipaddr of store1, port=27900, localport=abc...] --> appears only when store connected
4) WorkerThread#[idaddr of store1] --> this gets started the first time transaction data arrives from Store 1 and does not appear to go away
5) The MDB actually runs in a thread "JMS SessionPool Worker-z"
Is there some limitation on the number of remote MDBs that messaging can handle reliably? Exact same code, config etc works with smaller numbers of MDBs. With 400 MDBs it looks like just those could generate upto 2000 threads, assuming all stores are connected to our Central server. Does this pose any problems for Messaging?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546247#546247]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years