September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7251) Upgrade JGroups to 2.8.0.GA

by Brian Stansberry (JIRA)

Upgrade JGroups to 2.8.0.GA --------------------------- Key: JBAS-7251 URL: https://jira.jboss.org/jira/browse/JBAS-7251 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-7253) Don't assume Address object available from Channel is an IpAddress

by Brian Stansberry (JIRA)

Don't assume Address object available from Channel is an IpAddress ------------------------------------------------------------------ Key: JBAS-7253 URL: https://jira.jboss.org/jira/browse/JBAS-7253 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 In JGroups 2.8, the Address type will typically not be IpAddress, so simply casting the Address to IpAddress and passing it to the ClusterNodeImpl ctor is invalid. The calling node needs to find the underlying InetAddress/port from the JGroups channel and pass the values to the constructor. Instead something like this needs to be done to get the IpAddress: IpAddress physicalAddress = (IpAddress) channel.downcall(new Event(Event.GET_PHYSICAL_ADDRESS, a)); The ClusterNodeImpl.getOriginalJGAddress() method can be removed. It is not part of the ClusterNode interface, which is the API for this class. It is tempting to remove the ClusterNodeImpl.originalJGAddress field and change the ClusterNodeImpl ctor to take InetAddress + port instead of IpAddress. However, this changes the serialization format of the class. We'd need to have a jboss-dev list discussion before doing that. Eclipse reports 3 places where the ClusterNodeImpl ctor is called; 2 in ClusterPartition and one in RspFilterAdapter. RspFilterAdapter is called every time an RPC response comes in, so calling channel.downcall each time is clearly not reasonable. I think the thing to do is to find/cache in ClusterPartition the IpAddresses each time a new view comes in. In a ConcurrentMap<Address, IpAddress>. Then add a new IpAddressResolver interface that ClusterPartition implements by doing a map lookup or a channel.downcall is necessary. Probably better to use a separate class for this map/channel.downcall functionality. ClusterPartition will pass a ref to IpAddressResolver to any RspFilterAdapter it creates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-129) Implement support for the generic metadata in the javassist implementation of ClassInfo

by Adrian Brock (JIRA)

Implement support for the generic metadata in the javassist implementation of ClassInfo --------------------------------------------------------------------------------------- Key: JBMICROCONT-129 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-129 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock The support for generics has only been implemented in the reflection based ClassInfo implementation. This needs doing also for the Javassist implementation. -- 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

16 years, 3 months

6
9
0 / 0

[JBoss JIRA] Created: (JBAS-7219) Port the TS crash recovery tests from JBPAPP_5_0 to trunk

by Ivo Studensky (JIRA)

Port the TS crash recovery tests from JBPAPP_5_0 to trunk --------------------------------------------------------- Key: JBAS-7219 URL: https://jira.jboss.org/jira/browse/JBAS-7219 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Ivo Studensky Assignee: Ivo Studensky Fix For: JBossAS-6.0.0.Alpha1 Porting the JBossTS crash recovery tests from the JBPAPP_5_0 branch (EAP5) to the trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1392) WSRP does not submit the from when enctype set to "multipart/form-data"

by Andrey Adamovich (JIRA)

WSRP does not submit the from when enctype set to "multipart/form-data" ----------------------------------------------------------------------- Key: JBPORTAL-1392 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1392 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.CR2 Environment: All Reporter: Andrey Adamovich Assigned To: Chris Laprun We are developing a portlet on BEA WebLogic Portal that is supposed to be consumed later by JBoss Portal. This portlet is used for file data upload. The thing is that portlet contains a form that has enctype attribute set to multipart/form-data to enable file sending. When the form is submitted on the consumer (JBoss) no form parameters are passed to producer. Looking in the WSRP request sent to BEA Portal by JBoss only action name is seen. If enctype attribute is removed from the form then when form is submitted all parameters are sent to producer except file content. -- 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

16 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-6260) Configure JGroups sockets via ServiceBindingManager

by Brian Stansberry (JIRA)

Configure JGroups sockets via ServiceBindingManager --------------------------------------------------- Key: JBAS-6260 URL: https://jira.jboss.org/jira/browse/JBAS-6260 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, Management services Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 Get all port configuration under the SBM; JGroups is the major outlier. Create a system property for each address or port config item in jgroups-channelfactory-stacks.xml. Add ServiceBinding entries for each in bindings.xml. Set the system properties via SystemPropertyBinder. Add dependency on SystemPropertyBinder to the channel factory bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-7267) Add missing artifacts to the dependency chain

by Andrew Lee Rubinger (JIRA)

Add missing artifacts to the dependency chain --------------------------------------------- Key: JBAS-7267 URL: https://jira.jboss.org/jira/browse/JBAS-7267 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 A dependence upon the following should transitively bring in everything AS needs for the runtime:  <dependency> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-build</artifactId> <version>${version.org.jboss.jbossas}</version> <type>pom</type> </dependency> However, some modules are in the distribution which are not part of this chain. The following are a list of offenders manually added into the Embedded POM: <dependency> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-management</artifactId> <version>${version.org.jboss.jbossas}</version> <classifier>jsr77</classifier> </dependency> <dependency> <groupId>jboss.web</groupId> <artifactId>jsp-api</artifactId> <version>${version.jboss.web}</version> </dependency> <dependency> <groupId>jboss.web</groupId> <artifactId>el-api</artifactId> <version>${version.jboss.web}</version> </dependency> <dependency> <groupId>jboss.web</groupId> <artifactId>jasper-jdt</artifactId> <version>${version.jboss.web}</version> </dependency> <dependency> <groupId>jboss.messaging</groupId> <artifactId>jboss-messaging</artifactId> <version>${version.jboss.messaging}</version> </dependency> <dependency> <groupId>org.jboss.slf4j</groupId> <artifactId>slf4j-jboss-logging</artifactId> <version>${version.org.slf4j_slf4j.jboss.logging}</version> </dependency> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2067) Compilation performance for rules degrades as the classpath increases

by Edson Tirelli (JIRA)

Compilation performance for rules degrades as the classpath increases --------------------------------------------------------------------- Key: JBRULES-2067 URL: https://jira.jboss.org/jira/browse/JBRULES-2067 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.CR1 Reporter: Edson Tirelli Assignee: Mark Proctor Fix For: 5.0.0.GA REPORTED BY: Christian Nedregård ============================= This is now solved. I noticed that the problem became worse the bigger the classpath was, even if the extra jars contained totally irrellevant classes. Profiling revealed that the rule compilation generated an enomous amount of IO traffic from ClassLoader.loadClass originating from org.mvel.ParserContext.checkForDynamicImport and org.drools.rule.PackageCompilationData$PackageClassLoader. In both these places Drools generates a lot of loadClass calls for classes that does not exist. It seems like the Sun classloaders does not cache the result of failed class lookups, but scans the whole classpath again and again looking for these non-existing classes. That is why the problem gets bigger the larger your classpath is. Our classpath contains 100+ jars, so we got hit pretty bad. I solved the problem by creating a caching classloader that also caches the result of failed lookups. When I added this as the context classloader scoped around all my compilation I saw a performance increase of a factor of 10 - 20 in our various environments. Here are the stats from the caching classloader after compiling 850 rules: Caching loader called 200608 times 119 actual successful loads 932 actual failed loads 73738 cache hits for successfull loads 125819 cache hits for failed loads In other words: Drools generated 126751 loads for 932 non-existing classes. We saved 125819 full classapth scans by caching the failed lookups. As mentioned above the caching classloader can be hooked into the system by setting it at the context classloader. org.mvel.ParserContext.checkForDynamicImport uses the context classloader directly. org.drools.rule.PackageCompilationData$PackageClassLoader uses the classloader configured in PackageBuilderConfiguration which is the context classloader by default. This means you get the full effect only when you scope the caching class loader around all your PackageBuilderConfiguration and PackageBuilder usage. Below is the code for our caching classloader for the reference of anybody else who might encounter this problem. Regards Chr PS Edson: This problem is related to compilation. The RETE building is usually very fast. ---------------------------------------------- package domain.rules; import java.util.HashMap; import java.util.Map; /** * Classloader that intercepts calls to the current context class loader and caches the result of the calls to {@link #loadClass} * on it. * <p/> * The interception will start automagically when this class is instantiated. Make sure that you call {@link #stop()} from a finally * block when you want the loader interception to stop, to avoid unnecessary caching. * * @author Christian Nedregård * @see Thread#getContextClassLoader() */ public class CachingContextClassLoader extends ClassLoader { private Map classLoaderResultMap = new HashMap(); private ClassLoader originalClassLoader; private int successfulCalls = 0; private int failedCalls = 0; private int cacheHits = 0; private int successfulLoads = 0; private int failedLoads = 0; /** * Create an instance. The instance will automagically start intercepting {@link #loadClass(String)} calls to the current * context class loader. * * @see Thread#getContextClassLoader() */ CachingContextClassLoader() { super(Thread.currentThread().getContextClassLoader()); this.originalClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(this); } /** * Try to load the class from the original context class loader and chache the result (also <code>ClassNotFoundException</code>s). * Subsequent calls for the same class name will return the cached version, or throw a cached ClassNotFoundException if it was * not found initially. * * @param name the name of the class to find. * @return the cached result of a call to <code>loadClass</code> on the original context class loader. * @throws ClassNotFoundException when the class of the given name could not be found. */ public Class loadClass(String name) throws ClassNotFoundException { Object result; if (classLoaderResultMap.containsKey(name)) { ++cacheHits; result = classLoaderResultMap.get(name); } else { try { result = super.loadClass(name); ++successfulLoads; } catch (ClassNotFoundException e) { ++failedLoads; result = e; } classLoaderResultMap.put(name, result); } if (result instanceof ClassNotFoundException) { ++failedCalls; throw (ClassNotFoundException) result; } else { ++successfulCalls; return (Class) result; } } /** * Stop intercepting by resetting the original context classloader using {@link Thread#setContextClassLoader(ClassLoader)}. */ public void stop() { Thread.currentThread().setContextClassLoader(originalClassLoader); } /** * Get a textual report of the caching that was performed. * * @return a textual report of the caching that was performed. */ public String getReport() { return new StringBuffer("Loader called ").append(successfulCalls + failedCalls).append(" times, ").append(successfulCalls) .append(" successfull, ").append(failedCalls).append(" failed. Cache hits: ").append(cacheHits) .append(", successful loads: ").append(successfulLoads).append(", Failed loads: ").append(failedLoads) .append('.').toString(); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (JASSIST-42) Proxy serialization looses inner data objects

by Damien Lecan (JIRA)

Proxy serialization looses inner data objects --------------------------------------------- Key: JASSIST-42 URL: http://jira.jboss.com/jira/browse/JASSIST-42 Project: Javassist Issue Type: Bug Reporter: Damien Lecan Assigned To: Shigeru Chiba Priority: Blocker I working with proxies build with ProxyFactory method. When I want to serialize/deserialize it, everything seems to be ok except that only proxy instance is serialized, not inner objects. Eg. Object "A" contains an instance of "B" After serialization/deserialization of a proxy of A, instance of "B" in "A" is null When I look at this code : public static SerializedProxy makeSerializedProxy(Object proxy) throws java.io.InvalidClassException { Class clazz = proxy.getClass(); return new SerializedProxy(clazz, ProxyFactory.getFilter(clazz), ProxyFactory.getHandler(clazz)); } I don't understand how serialization can keep inner objects ... -- 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

16 years, 4 months

3
11
0 / 0

[JBoss JIRA] Created: (JBRULES-535) allow for plugeable query result handlers

by Mark Proctor (JIRA)

allow for plugeable query result handlers ------------------------------------------- Key: JBRULES-535 URL: http://jira.jboss.com/jira/browse/JBRULES-535 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Queries should be able to specify how the results are processed once they reach the terminal node. -- 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

16 years, 4 months

3
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 September 2009