May 2007 - jboss-jira - Jboss List Archives

[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

18 years

4
16
0 / 0

[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

18 years

1
3
0 / 0

[JBoss JIRA] Created: (JBWEB-68) Servlet.init(ServletConfig) not called

by Thomas Diesler (JIRA)

Servlet.init(ServletConfig) not called -------------------------------------- Key: JBWEB-68 URL: http://jira.jboss.com/jira/browse/JBWEB-68 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Remy Maucherat <componentref name="apache-tomcat" version="6.0-snapshot"/> [tdiesler@tdvaio trunk]$ svn info Path: . URL: https://svn.jboss.org/repos/jbossas/trunk Repository Root: https://svn.jboss.org/repos/jbossas Repository UUID: 84be2c1e-ba19-0410-b317-a758671a6fc1 Revision: 55837 Node Kind: directory Schedule: normal Last Changed Author: rrajesh Last Changed Rev: 55837 Last Changed Date: 2006-08-11 22:26:36 +0200 (Fri, 11 Aug 2006) <servlet> <servlet-name>TestService</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.endpoint.EndpointServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> -- 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

18 years

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4069) Test clustering in an 80 node cluster

by Brian Stansberry (JIRA)

Test clustering in an 80 node cluster ------------------------------------- Key: JBAS-4069 URL: http://jira.jboss.com/jira/browse/JBAS-4069 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, EJB3, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.GA Test in the Tyson's Corner lab (10 8-core boxes) Test web session clustering and EJB3 SFSB and entity clustering. -- 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

18 years

2
1
0 / 0

[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

18 years

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-3415) Port RARDeployer

by Scott M Stark (JIRA)

Port RARDeployer ---------------- Key: JBAS-3415 URL: http://jira.jboss.com/jira/browse/JBAS-3415 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services, JCA service Reporter: Scott M Stark Assigned To: Weston Price Fix For: JBossAS-5.0.0.Beta The RARDeployer needs to be ported or rewritten for the new VDF -- 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

18 years

5
15
0 / 0

[JBoss JIRA] Created: (JBAS-3836) Conditional setting of -server may not be supported on sun jdk1.3

by Dimitris Andreadis (JIRA)

Conditional setting of -server may not be supported on sun jdk1.3 ----------------------------------------------------------------- Key: JBAS-3836 URL: http://jira.jboss.com/jira/browse/JBAS-3836 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-3.2.8.SP2 The change in JBAS-3458 conditionally sets -server. Although sun jdk1.3 seems to support -server, it fails with: Unrecognized option: -server (although the forum post refers erroneously to 4.0.5, the error appears in the 3.2 branch, too). -- 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

18 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-720) Clips Parser

by Mark Proctor (JIRA)

Clips Parser ------------ Key: JBRULES-720 URL: http://jira.jboss.com/jira/browse/JBRULES-720 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 Clips Parser -- 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

18 years, 1 month

1
4
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-120) Add support for an LRU cache to CachingMetaDataContext

by Adrian Brock (JIRA)

Add support for an LRU cache to CachingMetaDataContext ------------------------------------------------------ Key: JBMICROCONT-120 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-120 Project: JBoss MicroContainer Issue Type: Feature Request Components: MetaData Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock The CachingMetaDataContext caches values indefinitely. Support for some kind of LRUCache (maybe across contexts) will help to relieve memory pressure when for example the metadata is actually only retrieved once and used at deployment. -- 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

18 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-4448) Properties MBean attribues don't update properly

by John Mazzitelli (JIRA)

Properties MBean attribues don't update properly ------------------------------------------------ Key: JBAS-4448 URL: http://jira.jboss.com/jira/browse/JBAS-4448 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.0.GA Reporter: John Mazzitelli Priority: Minor I have this in my jboss-service.xml for a custom MBean that has a Properties attribute: <attribute name="ConfigurationOverrides" serialDataType="jbxb"> <java:properties xmlns:java="urn:jboss:java-properties" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd"> <java:property> <java:key>my-data-directory</java:key> <java:value>${jboss.server.data.dir}/subdir</java:value> </java:property> ... and more java:property definitions ... I have other non-Properties attributes in my MBean as well. This works fine when starting up. My MBean's setConfigurationOverrides(Properties p) method is called with proper values and everything works. However, if I go to the JMX console, and edit one of my other attributes (simple String attribute), it seems my Properties attribute gets hosed - its values are all screwed up. -- 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

18 years, 1 month

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2007