[Performance Tuning] - Re: JBoss Community DOC-10217 - advice on tomcat connector t
by rhills
Hi Peter,
"PeterJ" wrote : The problem with using recommendations is that often they are specific to the environment of the user. And sometimes the recommendations are not necessarily the best especially if the recommendation is based on a performance test. For example, one of the recommendations is for setting sun.rmi.dgc.client.gcInterval to 60 minutes. Why 60 minutes? Because the specjappserver performance test runs in under 60 minutes so the "recommended" setting prevents stray full GCs from being called during the test run. But in a real life production environment, I would set it to once a day or once a week.
That's an excellent example. It's just a shame that the docs don't include that kind of qualification as well. I agree with you that it's almost impossible to provide recommendations that suit everybody. However I think that a set of recommendations for a specific set of circumstances with some explanation of why each value has been chosen would be a very useful document that most of us could then extrapolate to our own circumstances.
"PeterJ" wrote : Having said that, the Tomcat documents, since they describe the settings in general terms, are better references on how the settings work.
|
| (Examples below use the default values)
|
| MinSpareThreads is the minimum number of unused threads that will be kept available to handle new incoming requests. Example: if 20 threads are actively in use, there will be at least 24 threads (20 in use + 4 spare).
|
| A side effect is that this setting also dictates the initial number of threads created. Example: 0 threads in use, thus 4 threads. (I believe this is where the 'peak load' recommendation comes from - in a test such as specjappserver you can easily calculate the peak load and thus set minsparethreads to create that number of threads as part of system startup.)
|
| At some point the system might get busy and you end up with, say. 200 threads. Then everyone goes to lunch and only 20 threads are busy. When the idle thread timeout is reached, the thread count will be reduced to 70 (20 active plus 50 spare).
I agree, the Tomcat docs are better in this area, but I find your descriptions above even better still. It's a shame they're not in the Tomcat docs.
"PeterJ" wrote : Having said all of this, my testing has shown that Tomcat 6, and thus the versions of JBoss Web Server based on it, while it still accepts and stores these values no longer uses they to manage the threads. The min and max idle thread values are no longer checked in the source code (at least, it is no longer where it used to be checked and I haven't found any alternate locations where they are checked), and the observed behavior appears to validate the claim that they are no longer used.
Hmmm, for some silly reason, I'd thought JBoss was using 5.5 - I probably saw the number "5.5" somewhere and made the assumption without checking. Looking then at the http://tomcat.apache.org/tomcat-6.0-doc/config/http.html, no mention is made of the maxSpareThreads and minSpareThreads attributes, so that adds further evidence to your observations. Thanks for pointing that out.
Presumably, Tomcat now tunes itself for these parameters?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193636#4193636
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193636
17 years, 3 months
[JBoss Messaging] - JBM 1.4.0sp3 cp04 bisocket parameters does not effect
by lanceliao1
HI:
JBM Group.The para in remoting-bisocket-service.xml
| <attribute name="validatorPingPeriod" isParam="true">10000</attribute>
| <attribute name="validatorPingTimeout" isParam="true">5000</attribute>
does not effect client-side.So we got lots of disconnection.
The file of org.jboss.jms.client.remoting.JMSRemotingConnection.java
line 502
| /**
| * @return true if the listener was correctly installed, or false if the add attepmt was ignored
| * because there is already another listener installed.
| */
| public synchronized boolean addConnectionListener(ConsolidatedRemotingConnectionListener listener)
| {
| if (remotingConnectionListener != null)
| {
| return false;
| }
|
| client.addConnectionListener(listener);
| remotingConnectionListener = listener;
|
| return true;
| }
should use method:
| public void addConnectionListener(ConnectionListener listener, Map metadata)
|
otherwise the connectionValidator use default parameters to monitor connection.
validatorPingPeriod = 2000;
validatorPingTimeout = 1000;
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193633#4193633
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193633
17 years, 3 months
[JBoss AOP] - NoSuchMethodError: org.jboss.aop.ClassAdvisor$1
by svr.vin
Hi All
I am using JBoss-4.2.3.GA, JBoss-Messaging-1.4.0.GA And JDK1.6.0_07.
I am integrated the Jboss-messaging with JBAS and deployed my Application, the server started without any problem.
Added the following jar file in the client classpath
jboss-messaging.jar
jnpserver.jar
jbossall-client.jar
javassist.jar
jboss-aop.jar
trove.jar
Whenever i am calling my client application the following error is throwing.
Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: org.jboss.ao
| p.ClassAdvisor$1.<init>(Lorg/jboss/aop/ClassAdvisor;Lorg/jboss/aop/AspectManager
| ;Lorg/jboss/aop/ClassAdvisor;Ljava/lang/Class;)V
| at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
| at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java
| :591)
| at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:579)
| at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit
| >(ClientConnectionFactoryDelegate.java)
| at sun.misc.Unsafe.ensureClassInitialized(Native Method)
| at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAc
| cessorFactory.java:25)
| at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java
| :122)
| at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
| at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
| at java.lang.reflect.Field.getLong(Field.java:528)
| at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614
| )
| at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
| at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
| at java.security.AccessController.doPrivileged(Native Method)
| at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
| at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
| at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
| at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:158
| 3)
| at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
| 732)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
| at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:19
| 47)
| at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
|
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
| 753)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
| at java.rmi.MarshalledObject.get(MarshalledObject.java:142)
| at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:7
| 2)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:710)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at javax.naming.InitialContext.lookup(InitialContext.java:392)
| at com.bcsis.his.mq.HISConsumer.<init>(HISConsumer.java:33)
| at com.bcsis.his.socket.HISSender.init(HISSender.java:52)
| at com.bcsis.his.socket.HISSender.<init>(HISSender.java:44)
| at com.bcsis.his.socket.HISSdrManager.openConnection(HISSdrManager.java:
| 88)
| at HISLayout.createSTPConn(HISLayout.java:626)
| at HISLayout$1.actionPerformed(HISLayout.java:528)
| at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:19
| 95)
| at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
| a:2318)
| at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel
| .java:387)
| at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242
| )
| at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
| at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1
| 220)
| at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMen
| uItemUI.java:1261)
| at java.awt.Component.processMouseEvent(Component.java:6041)
| at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
| at java.awt.Component.processEvent(Component.java:5806)
| at java.awt.Container.processEvent(Container.java:2058)
| at java.awt.Component.dispatchEventImpl(Component.java:4413)
| at java.awt.Container.dispatchEventImpl(Container.java:2116)
| at java.awt.Component.dispatchEvent(Component.java:4243)
| at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322
| )
| at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
|
| at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
| at java.awt.Container.dispatchEventImpl(Container.java:2102)
| at java.awt.Window.dispatchEventImpl(Window.java:2440)
| at java.awt.Component.dispatchEvent(Component.java:4243)
| at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
| at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
| ad.java:273)
| at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
| java:183)
| at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
| ad.java:173)
| at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
|
| at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
|
| at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
|
please give me suggestion is there additional package required are anything i have to change.
Thanks in adv.
Srinivas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193632#4193632
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193632
17 years, 3 months
[JBoss Messaging] - Re: Number of topic subscribers
by clebert.suconic＠jboss.com
You shouldn't have any problems with that on JBoss Messaging 1.4.
I just ran a quick test where I had thousand subscribers and it ran without any problems.
When i say you shouldn't have any problems, I'm assuming you are designing your application well and you have considered resource usage on the server (max Openfiles set for the number of clients you will have, enough I/O and enough memory on the server and JVM).
If your consumers are local to the server, you should probably avoid ObjectMessage as Serialization will aways be something expensive (but that should be ok if your consumers are distributed. On the server side an ObjectMessage is just a ByteArray, but on the client that is using ObjectINputStream and if you have all the clients on the same server that will use more CPU power.
(Those recommendations will apply to any system you choose.. not just JBM)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193627#4193627
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193627
17 years, 3 months