September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1401) RELAY: messages lost when relay coordinator crashes

by Bela Ban (Created) (JIRA)

RELAY: messages lost when relay coordinator crashes --------------------------------------------------- Key: JGRP-1401 URL: https://issues.jboss.org/browse/JGRP-1401 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.1 When we have sites {A,B,C} and {X,Y,Z} (with relay coords A and X), during the time X leaves (or crashes) and Y taking over, all messages sent by the first site are not relayed to the second site. Because the sites are autonomous, there won't be any retransmission of the dropped messages. This can have an adverse affect, e.g. in Infinispan: - Say key K is stored on A, B and Z - Now we're updating K, on A and B, but before the change is relayed to the other site, X crashes - If there is no rebalancing, e.g. because K is still to be stored on A, B and Z, since the update on Z was dropped, Z has a stale value ! SOLUTION 1: - Have a backup coordinator B cache the last N messages in memory (with overflow to disk) - A numbers relayed messages - As soon as A has relayed message #50, it sends this info to B. Or, alternatively, this could be done periodically, or based on the number of relayed messages (e.g. every 10 messages) - B can then purge those messages - When A crashes, B runs a reconciliation protocol with X to determine whether to relay some backed up messages - C now starts acting as backup relay to B This solution is probably the simplest to implement, and doesn't require any code changes in Infinispan. However, there is still a chance of message loss if both the relay *and* the backup relay crash at the same time. SOLUTION 2: - After a crash (not a graceful leave !) of a relay coordinator, there has to be a full rebalancing of all keys - This is wasteful though - May not be needed, perhaps Infinispan could check whether a full rebalancing is required ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] (AS7-5365) Intermittent failure due to missing OSGi service

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5365: ----------------------------------- Summary: Intermittent failure due to missing OSGi service Key: AS7-5365 URL: https://issues.jboss.org/browse/AS7-5365 Project: Application Server 7 Issue Type: Bug Components: OSGi, Server Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.CR1 For the first OSGi related deployments we intermittently see {code} JBAS015870: Deploy of deployment "webapp.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER Missing[JBAS014861: <one or more transitive dependencies>]"]} {code} which is due to a race condition at subsystem startup. h4. Background At startup the framework goes through various phases # Framework.CREATE # Framework.INIT # Framework.ACTIVE During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings. In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down. Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services. AFAICS, there is currently no way to model this type of dependency properly without having this race condition. A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed) h4. Example * serviceA depends on serviceB with DependencyType.WEAK * serviceA starts when serviceB has started * serviceA stays UP when serviceB gets removed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
7
0 / 0

[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved AS7-5497. --------------------------------- Fix Version/s: 7.1.3.Final (EAP) 7.2.0.Alpha1 Resolution: Done > Exception handling of EJB container for MDB is incorrect > -------------------------------------------------------- > > Key: AS7-5497 > URL: https://issues.jboss.org/browse/AS7-5497 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.2.Final (EAP) > Environment: JBoss EAP 6.0.0 > Reporter: Adam Kovari > Assignee: JBoss SET > Priority: Minor > Labels: eap6, ejb3.1 > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > After deploying a MDB with Container-Managed transaction and > TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from > within the MDB onMessage() is reported to the Adapter as such, with no > EJBException wrapping. I.e.: the "((javax.jms.MessageListener) > endPoint).onMessage(message)" call in our adapter fails with the > exception type originally thrown. > This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise > JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right): > "Throw EJBException that wraps the original exception to resource > adapter". > Another part of spec I was just made aware of says this: > p383 of the spec states - > In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5566) Add support for @PersistenceContexts and @PersistenceUnits

by Scott Marlow (JIRA)

Scott Marlow created AS7-5566: --------------------------------- Summary: Add support for @PersistenceContexts and @PersistenceUnits Key: AS7-5566 URL: https://issues.jboss.org/browse/AS7-5566 Project: Application Server 7 Issue Type: Bug Components: JPA / Hibernate Affects Versions: 7.1.2.Final (EAP) Reporter: Scott Marlow Assignee: Scott Marlow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] (AS7-5429) JDBC connections not released when using EJB 2.x entity beans

by Viggo Navarsete (JIRA)

Viggo Navarsete created AS7-5429: ------------------------------------ Summary: JDBC connections not released when using EJB 2.x entity beans Key: AS7-5429 URL: https://issues.jboss.org/browse/AS7-5429 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.2.Final (EAP) Reporter: Viggo Navarsete Assignee: Jason Greene -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
7
0 / 0

[JBoss JIRA] (AS7-5288) Tests failing Intermittently on slow machines - iiop.basic.BasicIIOPInvocationTestCase

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-5288: --------------------------------- Summary: Tests failing Intermittently on slow machines - iiop.basic.BasicIIOPInvocationTestCase Key: AS7-5288 URL: https://issues.jboss.org/browse/AS7-5288 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.1.2.Final (EAP) Reporter: Ondrej Zizka Assignee: Ivo Studensky These tests fail intermittently on really slow machines. To reproduce, try to run in EC2 on 32-bit "small" instance type. https://jenkins-jbossqa.rhcloud.com/job/EAP6-EC2/61/#showFailuresLink org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testRemoteIIOPInvocation org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testHomeHandle org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testHandle org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testWrappedHandle org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testEjbMetadata org.jboss.as.test.iiop.basic.BasicIIOPInvocationTestCase.testIsIdentical -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
4
0 / 0

[JBoss JIRA] (AS7-3081) Misplaced @PersistenceContext Causes Untraceable Deployment Failure

by Jim Brownfield (Created) (JIRA)

Misplaced @PersistenceContext Causes Untraceable Deployment Failure ------------------------------------------------------------------- Key: AS7-3081 URL: https://issues.jboss.org/browse/AS7-3081 Project: Application Server 7 Issue Type: Bug Components: JPA / Hibernate Affects Versions: 7.0.2.Final Environment: Macintosh 10.7.2 Reporter: Jim Brownfield Assignee: Scott Marlow When deploying an ear file that contains an Entity bean with an inappropriate @PersistenceContext annotation, the following stacktrace is generated, and the deployment fails: 15:36:16,322 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.deployment.subunit."xxx.xxxxxx.xxxxx.deploy.ear"."xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."xxx.xxxxxx.xxxxx.deploy.ear"."xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar".PARSE: Failed to process phase PARSE of subdeployment "xxx.xxxxxx.xxxxx.ejb-0.0.1-SNAPSHOT.jar" of deployment "xxx.xxxxxx.xxxxx.deploy.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29] at java.lang.Thread.run(Thread.java:680) [:1.6.0_29] Caused by: java.lang.IllegalArgumentException: Class level annotations must provide a name. at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processClass(JPAAnnotationParseProcessor.java:233) at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:127) at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final] ... 5 more The IllegalArgumentException gives no data for the annotation, the class, or any relevant data to the cause. I built JBoss debug from source to discover that the culprit in my case was a misplaced PersistenceContext annotation in an entity bean. The offending annotation had actually existed in a version of our code running in JBoss 4 without error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
8
0 / 0

[JBoss JIRA] (AS7-5012) Mod_cluster load-metric incorrect default value

by Stefan Negrea (JIRA)

13 years, 9 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-8414) Enable schema validation in development

by Thomas Diesler (JIRA)

Enable schema validation in development --------------------------------------- Key: JBAS-8414 URL: https://jira.jboss.org/browse/JBAS-8414 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: XML services Reporter: Thomas Diesler Assignee: Alexey Loubyansky Fix For: 7.0.0.M1 The server configuration that we ship (i.e. standalone.xml) should be in sync with the schemas that it references If there is no automated schema validation chances are high that the xml configuration is not in sync with the respective subsystem schemas, which should be the input for tooling I suppose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

7
14
0 / 0

[JBoss JIRA] (AS7-5142) Test MavenURLResourceTestCase#testMavenGav fails with Connection timed out

by Hauke Mehrtens (JIRA)

Hauke Mehrtens created AS7-5142: ----------------------------------- Summary: Test MavenURLResourceTestCase#testMavenGav fails with Connection timed out Key: AS7-5142 URL: https://issues.jboss.org/browse/AS7-5142 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.3.Final (EAP) Reporter: Hauke Mehrtens Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 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 2012