[Beginners Corner] - Re: MDB cannot be created when running in
by jaikiran
"gan.gary" wrote :
|
| but when runnning in "all" configuration, the MDB only can be created by first Jboss (let say: 10.10.10.10) in network, the subsequent running JBoss instance ((let say: 10.10.10.11, 10.10.10.12) detected the running instance, seems clustering it automatically, causes the MDB on folowing JBoss instance cannot created. Any idea?
When you say, the MDB fails, do you see any exception (I remember seeing your other post where you had posted about NameNotFoundException, is it the same exception you are seeing)?
In the "all" configuration, the queues are deployed in the deploy-hasingleton folder. According to the docs http://wiki.jboss.org/wiki/HASingletonDeployer
anonymous wrote :
| deploy-hasingleton Directory
|
| Since JBoss 3.2.4, server configuration "all " offers a deployment directory that contains services that are deployed on exactly one node in the cluster.
So anything in this folder will be deployed only on one node.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172366#4172366
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172366
17 years, 8 months
[JBoss Portal] - Re: Portlet Security Constraints
by jelavallee
Peter,
The Admin Console is fine except for the need for this to be automated from deployment scripts and reproducible w/o manual intervention.
Our solution is going to be implementing an automated mapper for building out our individual portlet-instances.xml permissions across the dozen or so portlet application WARs that are in our deployment package.
Will be adding this to the list along with a *-object.xml topology exporter utility.
On a purely academic level, it doesn't make a lot of sense to be binding the instance security configs with the web app deployment file in a portal framework/topology. This situation is an excellent example why, actually... we have four separate "portals" being hosted on one server but sharing certain generic components. If one portal's security profiles and portlet permissions need modification it will mean a re-deployment of the entire EAR, rather than just a secodary configuration WAR (like what we're doing with managing topology in a separate WAR). Based on experience with a number of other portal frameworks this level of separation can be very valuable when measuring risk/impact of deployment execution.
Thanks for the info!
cheers,
Etienne
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172365#4172365
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172365
17 years, 8 months
[Performance Tuning] - Re: JVM pauses periodically
by PeterJ
Smaller young generations get collected more often, which means that objects will more quickly use up their 32 (by default) lives before being placed into into the tenured generation. Thus medium-lived objects tend to end up in the tenured generation. By keeping your young generation larger, you are more apt to "kill" medium-lived objects via a minor collections because there are fewer of them.
In one test (on a real-world application, not on a test app) I saw the number of collections go from over 8000 to under 100 by right-sizing the young generation. The total time spent in GC was also drastically reduced from several minutes to under one minute.
Both size and number of live objects are factors in GC time. Larger heaps take longer to collect. Given two heaps of the same size, the one with the most number of live objects takes the longest to collect.
Parallel collection helps, given one CPU/core per thread. Fortunately, parallel collection is turned on by default starting with JVM 1.5 if you have two CPUs/cores and at least 1GB or RAM (yes RAM, not heap size).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172349#4172349
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172349
17 years, 8 months
