[JBoss JIRA] Created: (JBAS-4287) run.sh can consume 100% single CPU resources on Solaris
by Quenten Alick (JIRA)
run.sh can consume 100% single CPU resources on Solaris
-------------------------------------------------------
Key: JBAS-4287
URL: http://jira.jboss.com/jira/browse/JBAS-4287
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Environment: Solaris on SPARC (version 9 & 10)
Reporter: Quenten Alick
When shutting down jboss the run.sh script remain alive and consumes 100% of a single CPUs resources. run.sh needs to be killed off.
To trigger the bug, you need to
1) set LAUNCH_JBOSS_IN_BACKGROUND
2) start the jboss server normally
3) Once it's started stop the server
At this point the JVM stops, however the run.sh script remains running consuming 100% of a single CPUs resources.
The problem seems to be this bit of script, plus the fact that the script shebang is #!/bin/sh
while [ "$WAIT_STATUS" -ne 127 ]; do
JBOSS_STATUS=$WAIT_STATUS
wait $JBOSS_PID 2>/dev/null
WAIT_STATUS=$?
done
On Solaris, /bin/sh is *real* bourne shell and the wait shell-built-in for /bin/sh on Solaris returns 0 (not 127) if the PID (passed as an argument) doesn't exist. The man page for wait states that this is the correct behaviour. Therefore wait returns 0 and the while loop continues forever burning up CPU resources (until you kill it with one of the signals not being trapped).
Here's a link to the patch that may have introduced the bug.
http://jira.jboss.com/jira/browse/JBAS-3748
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months
[JBoss JIRA] Created: (JGRP-511) FC: dynamically adjust credits
by Bela Ban (JIRA)
FC: dynamically adjust credits
------------------------------
Key: JGRP-511
URL: http://jira.jboss.com/jira/browse/JGRP-511
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
FC currently has a static number of credits (max_credits). It would be beneficial to implement something similar to TCP's exponential backoff and slow start, to take the message loss rate into account.
Goal: when there is an overload, we reduce the credits in order to avoid compounding the overload by sending messages. On the other hand, we can send more messages when the receiver(s) have free capacity. To do this, each receiver sends the number of credits it can accept with its responses. By default, this would be the default number of credits (in TCP: size of the sliding window).
DESIGN:
NAKACK (and/or UNICAST) send the loss rate (rolling average of number of messages missing over number of messages received, per sender) when it exceeds a certain value (defined in NAKACK,UNICAST) up the stack.
FC looks at the loss rate and slices the number of credits for that sender in half (exponential backoff). On the next response, it piggy backs the new number of credits, so that sender will block sending messages.
When the loss rate drops below a certain (predefined) value, NAKACK sends another event up the stack. FC then increases the credits by a predefined value (slow start). Next time, it increases the value by the predefined value by 2 and so on, until the max number of credits have been reached again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months
[JBoss JIRA] Created: (JBCLUSTER-150) CNFE issues with Hibernate and JBoss Cache
by Brian Stansberry (JIRA)
CNFE issues with Hibernate and JBoss Cache
------------------------------------------
Key: JBCLUSTER-150
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-150
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: Q4Y6
Hibernate w/ JBC as 2nd level cache can potentially place instances of custom user classes in the cache. Can happen if the query cache is used, since instances of custom classes can be parameters to queries.
This leads to replication or state transfer problems like the following if the custom classes are not visible to JBC's classloader (i.e. the custom classes aren't in server/all/lib). For regular entity caching, Hibernate stores primitives in the cache, so this is less of an issue. Problem is more with the query cache.
java.lang.ClassNotFoundException: No ClassLoaders found for: services.entities.ProductDemandPK
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.j
ava:109)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.Fqn.readExternal(Fqn.java:355)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.loader.NodeData.readExternal(NodeData.java:59)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:241)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateStateTransferChildren(
StateTransferIntegrator_140.java:271)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:222)
at org.jboss.cache.statetransfer.StateTransferIntegrator_140.integrateTransientState(StateTr
ansferIntegrator_140.java:97)
at org.jboss.cache.TreeCache._setState(TreeCache.java:2640)
at org.jboss.cache.TreeCache.access$000(TreeCache.java:86)
at org.jboss.cache.TreeCache$MessageListenerAdaptor.setState(TreeCache.java:5306)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:614)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:331)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:55
4)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:595)
JBC's region-based marshalling API is meant for dealing with this kind of thing. Need to see how Hibernate can be configured to work with this API. Expect this will lead to JIRAs in the Hibernate and possible EBJ3 project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months