jboss-jira May 2010

jboss-jira@lists.jboss.org

1 participants
1566 discussions

[JBoss JIRA] Created: (JGRP-692) Unable to recover from suspect/merge, with auto-reconnect

by Matt Magoffin (JIRA)

Unable to recover from suspect/merge, with auto-reconnect --------------------------------------------------------- Key: JGRP-692 URL: http://jira.jboss.com/jira/browse/JGRP-692 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: JBoss 4.2.2 on Linux 2.4.21-47.0.1.ELsmp i686 using Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) Reporter: Matt Magoffin Assigned To: Bela Ban Attachments: jgroups-logs.tbz2 I'm having an issue with a 2-machine cluster using a TCP stack based on the tcp.xml from JGroups 2.6.1. On each machine I have 8 separate channels running, on different ports, with 4 groups in 2 JVM instances. After some period of time, one machine will fail to respond to a FD ping, and gets suspected. The machine that failed is not responding in time it seems from high CPU use, and many of the channels will fail FD around the same time. The channels are configured with auto-reconnect. My understanding was that the channel should "heal" itself and eventually re-form into a new view with the same 2 members in the cluster, which should apply to this situation because the machine that failed to respond eventually will respond. However, the group does not always seem to "heal" (sometimes it does, sometimes not). Once it stops healing, it never seems to ever do so again, and I get tons of NAKACK "message X not found in retransmission table" ERROR logs. The only way to get the channel working agin is to shut down the channel on both machines and then start them up again. I'm not using muxed channels... just normal channels. I have for now disabled shunning, and the channels seem to be able to re-connect after a shun situation occurs, but after time I'm still seeing something wrong with the channel in that the nodes are not able to send messages to each other successfully, and I have tons of 2008-02-21 21:01:53,572 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] log entries, even while FD is receiving acks on that channel. this is a degradation problem for me while my servers are running, not just during deployment. After a while of running, the nodes get shunned/disconnected some how (often from a slow response from the other node) and then fail to ever merge back to form the original view of the 2 nodes again. Now even with shun set to false in both FD and pbcast.GMS on both nodes for all channels, eventually still the nodes reach the same state of never re-forming... and I have tons eventual 2008-02-21 21:28:24,857 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] After a while in my application I'll force the channel to close wait a minute, and reopen, and sometimes this gets the channel working again, but doesn't always seem to. -- 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, 2 months

4
24
0 / 0

[JBoss JIRA] Created: (JBAS-7594) Seam testsuite ears fail to deploy due to parse issues

by Scott M Stark (JIRA)

Seam testsuite ears fail to deploy due to parse issues ------------------------------------------------------ Key: JBAS-7594 URL: https://jira.jboss.org/jira/browse/JBAS-7594 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-6.0.0.M1 Reporter: Scott M Stark The seam apps are failing to deploy due to some xml ordering issue that must have become more strict recently, or the seam examples have changed. Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{"http://java.sun.com/xml/ns/javaee":type, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method}' is expected. @ vfszip:/Users/svn/JBossHead/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jboss-seam-numberguess.ear/jboss-seam-numberguess.war/WEB-INF/lib/jboss-seam-ui.jar/META-INF/s.tld[2205,18] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:229) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:62) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:37) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{"http://java.sun.com/xml/ns/javaee":type, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method}' is expected. @ vfszip:/Users/svn/JBossHead/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-ui.jar/META-INF/s.tld[2205,18] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:229) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:62) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:37) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) -- 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, 2 months

4
13
0 / 0

[JBoss JIRA] Created: (JBAS-7872) Update ClusterCacheTester to use JMXConnectorFactory instead of RMIAdaptor for cluster unit testing

by Scott Marlow (JIRA)

Update ClusterCacheTester to use JMXConnectorFactory instead of RMIAdaptor for cluster unit testing --------------------------------------------------------------------------------------------------- Key: JBAS-7872 URL: https://jira.jboss.org/jira/browse/JBAS-7872 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Scott Marlow Fix For: JBossAS-6.0.0.M4 Using JMXServiceURL "service:jmx:rmi:///jndi/rmi://localhost:8099/jmxrmi" (will need binding support for new rmi registry port + rmi connector), obtain JSR-160 style jmx connectors for cluster nodes. For example: JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:8099/jmxrmi"); JMXConnector jmxc = JMXConnectorFactory.connect(url, new HashMap()); return jmxc.getMBeanServerConnection(); -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-7826) Port the org.jboss.varia JMX ant task to act as a JSR-160 client

by David Lloyd (JIRA)

Port the org.jboss.varia JMX ant task to act as a JSR-160 client ---------------------------------------------------------------- Key: JBAS-7826 URL: https://jira.jboss.org/jira/browse/JBAS-7826 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMX Reporter: David Lloyd Fix For: JBossAS-6.0.0.M3 -- 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, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5558) AnnotationMetaDataDeployer should be rewritten to not load the classes

by Kabir Khan (JIRA)

AnnotationMetaDataDeployer should be rewritten to not load the classes ---------------------------------------------------------------------- Key: JBAS-5558 URL: http://jira.jboss.com/jira/browse/JBAS-5558 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.CR1 -- 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, 2 months

5
14
0 / 0

[JBoss JIRA] Created: (JBAS-6225) MetaData repository loader for ServiceMetaData annotations

by Scott M Stark (JIRA)

MetaData repository loader for ServiceMetaData annotations ---------------------------------------------------------- Key: JBAS-6225 URL: https://jira.jboss.org/jira/browse/JBAS-6225 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: MicroContainer bus, ProfileService, System service Affects Versions: JBossAS-5.0.0.CR2 Reporter: Scott M Stark Assignee: Ales Justin Fix For: JBossAS-5.0.0.GA See forum discussion about how we can introduce an annotation such as: <annotation> @org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO) </annotation> For all org.jboss.jms.server.destination.QueueService rather than having to add the annotation to each mbean deployment: <mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=DLQ" xmbean-dd="xmdesc/Queue-xmbean.xml"> <annotation>@org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO)</annotation> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> </mbean> -- 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, 2 months

3
2
0 / 0

← Newer
1
...
154
155
156
157
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010