March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6941) consistency between XSD, propOrder and XML in the MC

by Alexey Loubyansky (JIRA)

consistency between XSD, propOrder and XML in the MC ---------------------------------------------------- Key: JBAS-6941 URL: https://jira.jboss.org/jira/browse/JBAS-6941 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossAS-5.1.1.GA E.g. currently in SVN for beanType <xsd:complexType name="beanType"> <xsd:sequence> <xsd:element name="alias" type="aliasType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="related-class" type="relatedClassType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="annotation" type="annotationType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="classloader" type="classloaderType" minOccurs="0"/> <xsd:element name="constructor" type="constructorType" minOccurs="0"/> <xsd:element name="property" type="propertyType" minOccurs="0" maxOccurs="unbounded"/> ... @XmlType(name="beanType", propOrder={"aliasMetaData", "related", "annotations", "classLoader", "constructor", "properties", "create", "start", "stop", "destroy", "depends", "demands", "supplies", "installs", "uninstalls", "installCallbacks", "uninstallCallbacks"}) public class AbstractBeanMetaData extends AbstractFeatureMetaData ... vfs.xml <bean name="VFSCache"> <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance">  <parameter>org.jboss.virtual.plugins.cache.CombinedVFSCache</parameter> </constructor> <start ignored="true"/> <property name="permanentRoots"> ... -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1042) Provide better reporting of ChannelExceptions when debugging

by Richard Achmatowicz (JIRA)

Provide better reporting of ChannelExceptions when debugging ------------------------------------------------------------ Key: JGRP-1042 URL: https://jira.jboss.org/jira/browse/JGRP-1042 Project: JGroups Issue Type: Feature Request Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Priority: Minor I spent a lot of time recently trying to track down some testsuite failures, where tests were failing with: "failed to start protocol stack" org.jgroups.ChannelException at org.jgroups.JChannel.startStack(JChannel.java:1766) at org.jgroups.JChannel.connect(JChannel.java:407) at org.jgroups.JChannel.connect(JChannel.java:382) at org.jgroups.tests.ChannelTest.testBasicOperations(ChannelTest.java:27) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:49) at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:40) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Turning on DEBUG level logging didn't help. I finally tracked the error down to an UnknownHostException which was getting raised in UDP.createSockets() during a call to InetAddress.getByname(). This checked exception was then passing through the following methods: UDP.createSockets() throws Exception ; UDP.start() throws Exception ; ProtocolStack.startStack() throws Exception ; JChannel.startStack() throws ChannelException ; There are a lot of potential exceptions which can occur when starting a stack, and these are getting masked to a large extent. It makes debugging stack startup problems painful, as the only way to get more information about the problem is to write code to unpack the ChannelException and print out its cause. I'd like to add some simple logging statements to the exception handler in JChannel.startStack() to make debugging the startup of stacks easier. -- 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

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1156) Recreate socket on NoRouteToHost exception

by Bela Ban (JIRA)

Recreate socket on NoRouteToHost exception ------------------------------------------ Key: JGRP-1156 URL: https://jira.jboss.org/jira/browse/JGRP-1156 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 I've got a customer [1] that started receiving the following error during multicast sends (from MERGE in this particular log) until JBoss was restarted: [Email Dennis] [org.jgroups.protocols.UDP] [ERROR] failed sending message to null (0 bytes) java.net.NoRouteToHostException: No route to host: Datagram send failed I've had one other case with this symptom. In that case, they had bonded network interfaces and were testing failover by bringing one side of it down. It looks to me like something is screwed up at the OS level that doesn't get fixed until JBoss is restarted (or the socket is recreated?). Is there anything we could do about this at the JGroups level? The customer has asked why we don't recreate the socket when this exception happens. But that doesn't seem like a good solution to me since there's nothing about a NoRouteToHostException that should indicate the socket needs recreated. -Dennis [End email Dennis] One thing we could investigate is to close and recreate a socket when such an exception is encountered. Possibly other exceptions as well... This would affect the transports (UDP and TCP), plus some of the protocols which use sockets, e.g. MPING, FD_SOCK, STREAMING_STATE_TRANSFER etc... -- 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

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1177) Multiple components using the same channel

by Bela Ban (JIRA)

Multiple components using the same channel ------------------------------------------ Key: JGRP-1177 URL: https://jira.jboss.org/jira/browse/JGRP-1177 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 Investigate sharing a channel between multiple components. Unlike the Multiplexer, this is light weight and doesn't require service views or other kludges ! Attached is an example of how this could be implemented. This JIRA is only to investigate whether being able to share a channel between multiple components makes sense, or whether a shared transport is better suited. We do NOT want to re-create the Multiplexer, which to this day still haunts me ! -- 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

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2465) Corruption of Rete when removing complex NotNodes

by Andreas Kohn (JIRA)

Corruption of Rete when removing complex NotNodes ------------------------------------------------- Key: JBRULES-2465 URL: https://jira.jboss.org/jira/browse/JBRULES-2465 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Reporter: Andreas Kohn Assignee: Mark Proctor Attachments: drools-core-betanode-remove.diff while working further on our drools integration we came across an odd exception when removing a particular rule: java.lang.IllegalArgumentException: Cannot remove a sink, when the list of sinks is null at org.drools.reteoo.ObjectSource.removeObjectSink(ObjectSource.java:159) at org.drools.reteoo.RightInputAdapterNode.doRemove(RightInputAdapterNode.java:217) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:275) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:280) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:387) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:237) at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:371) at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:746) While stepping through the code it looked like the network was corrupt (there was indeed no sinks on the ObjectSource, but the node calling removeObjectSink was still linked to it and claiming it as source). The rule itself contains multiple NotNodes, checking a condition that looks like this: not(not(Foo.v = X) and not(Foo.v = Y)) I could track this down to some sort of "loop" in the rete that triggers this when the outer not node is removed. When removing BetaNode#doRemove() first walks along 'rightInput': this.rightInput.remove( context, builder, this, workingMemories ); and eventually _in that call_ it also hits a node that is the direct 'leftInput' of the original beta node. The removal marks that node as visited in the removal context, and when the 'rightInput.remove' returns to the beta node it does not visit the leftInput due to this condition in BetaNode#doRemove(): if ( !context.alreadyVisited( this.leftInput ) ) { this.leftInput.remove( context, builder, this, workingMemories ); } In other words: before the remove the BetaNode had another node that was both referenced directly as 'leftInput', as well as an input to the 'rightInput'. The first removal of the rule "worked", and no exceptions happened. But: any further attempt to re-add the same rule and remove it again lead to the exception above. I was able to fix it with the attached patch, reproduced here: + boolean needRemoveFromLeft = !context.alreadyVisited( this.leftInput ); this.rightInput.remove( context, builder, this, workingMemories ); - if ( !context.alreadyVisited( this.leftInput ) ) { + if ( needRemoveFromLeft ) { this.leftInput.remove( context, builder, this, workingMemories ); } With this patch applied I could add/delete/add the particular rule repeatedly without problems. The attached patch also adds an assert in ObjectSource#removeObjectSink(): when removing a sink from an object source with only one sink the sink was unconditionally replaced with an empty sink, although the argument ObjectSink could be a different sink than the one in the ObjectSource. For CompositeObjectSinkAdapters this case is checked, but not for single sinks. I originally suspected that place to be responsible for the problem I observed but the assertion never fired in my tests. (taken from rules-dev mail "Bug in BetaNode#doRemove()?" -- 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

14 years, 8 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-7676) ejbClass is null in JBossEnterpriseBeanMetaData

by Pete Muir (JIRA)

ejbClass is null in JBossEnterpriseBeanMetaData ----------------------------------------------- Key: JBAS-7676 URL: https://jira.jboss.org/jira/browse/JBAS-7676 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Environment: r100034 Reporter: Pete Muir Assignee: Carlo de Wolf Fix For: JBossAS-6.0.0.M2 When deploy the classes in http://anonsvn.jboss.org/repos/weld/cdi-tck/tags/1.0.1-CR1/impl/src/main/... as an EAR with all classes placed in the ejb-jar (see attached for archive), the JBossEnterpiseBeanMetaData is giving a null for the BorderCollie SLSB (it didn't do this on 6.0 M1 or 5.1). To reproduce, just put the EAR into the deploy dir. To debug, you will need the sources for weld-jboss-int - http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/trunk/ - and you can break inside the constructor for JBossEJBDescriptorAdaptor. For now I will disable the test in CDI TCK with this issue as the reason -- 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

14 years, 8 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-7845) Upgrade jboss-ejb-api_3.1_spec to 1.0.0.Beta2

by jaikiran pai (JIRA)

Upgrade jboss-ejb-api_3.1_spec to 1.0.0.Beta2 --------------------------------------------- Key: JBAS-7845 URL: https://jira.jboss.org/jira/browse/JBAS-7845 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: JBossAS-6.0.0.M3 Upgrade to the recently released 1.0.0.Beta2 of org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec -- 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

14 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7614) Implementing PrefixDeploymentSorter feature in JBoss5.

by Vicky Kak (JIRA)

Implementing PrefixDeploymentSorter feature in JBoss5. ------------------------------------------------------ Key: JBAS-7614 URL: https://jira.jboss.org/jira/browse/JBAS-7614 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA Reporter: Vicky Kak Assignee: Ales Justin -- 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

14 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JGRP-1179) Incoming PingRsp is ignored despite being sent by a Coordinator.

by Renaud Devarieux (JIRA)

Incoming PingRsp is ignored despite being sent by a Coordinator. ---------------------------------------------------------------- Key: JGRP-1179 URL: https://jira.jboss.org/jira/browse/JGRP-1179 Project: JGroups Issue Type: Bug Affects Versions: 2.6.14, 2.6.9 Environment: Linux Red Hat Enterprise 5.0 kernel 2.6.18-8.el5 java 1.6.0_18 Reporter: Renaud Devarieux Assignee: Bela Ban I launch successively (nearly simultaneously) 5 nodes A B C D E using the same protocol stack and one channel to communicate between themselves. UDP(mcast_addr=231.8.8.8;mcast_port=45578):PING(num_initial_members=4):MERGE2:FD:VERIFY_SUSPECT:pbcast.NAKACK:pbcast.STABLE:FRAG2:pbcast.GMS(shun=true):pbcast.FLUSH Often as not, it depends on the speed/rythm between each node launch, I get 2 views, ie {D} and {A B C E}. Merge occurs later but when it does it's a bit late for my application and I don't think I should have to handle one save in case of a real electric/network failure. I noticed that on D I was timing out (3000ms) on during the discovery process despite having received the 4 GET_MBRS_RSP of the other nodes. Then D would decide there was no coordinator outside and become coordinator itself. What seems to happen is D sends two GET_MBRS_REQ and A replies to both, but at the time of the first reply, A is not yet coordinator and when D receives the second response, A became coordinator but D ignores the response and doesn"t add it to its list of Responses. I have written a workaround in Discovery.Responses method addResponse, it seems to work for my case but I am afraid it would break something else I am not aware of. public void addResponse(PingRsp rsp) { if(rsp == null) return; promise.getLock().lock(); try { //Workaround 29/03/2010 int index = ping_rsps.indexOf(rsp); // equivalent to does not contain. if (index == -1) { ping_rsps.add(rsp); promise.getCond().signalAll(); } else if (rsp.isCoord()) { PingRsp pr = ping_rsps.get(index); //Check if the already existing element is not server if (!pr.isCoord()) { ping_rsps.set(index, rsp); promise.getCond().signalAll(); } } /*if(!ping_rsps.contains(rsp)) { ping_rsps.add(rsp); promise.getCond().signalAll(); }*/ // Old JGroups code } finally { promise.getLock().unlock(); } } Regards Renaud -- 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

14 years, 9 months

3
10
0 / 0

[JBoss JIRA] Created: (JBBUILD-592) Update the deployment URLs of the jboss parent pom to point to the new repository

by Paul Gier (JIRA)

Update the deployment URLs of the jboss parent pom to point to the new repository --------------------------------------------------------------------------------- Key: JBBUILD-592 URL: https://jira.jboss.org/jira/browse/JBBUILD-592 Project: JBoss Build System Issue Type: Task Components: JBoss Parent POM Reporter: Paul Gier Assignee: Paul Gier Fix For: JBoss Parent POM - 5 -- 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

14 years, 9 months

1
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010