[JBoss JIRA] (JGRP-1485) JOIN attempts timing out indefinitely
by David Hotham (JIRA)
David Hotham created JGRP-1485:
----------------------------------
Summary: JOIN attempts timing out indefinitely
Key: JGRP-1485
URL: https://issues.jboss.org/browse/JGRP-1485
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: David Hotham
Assignee: Bela Ban
The good news is that my testing is currently avoiding JGRP-1451 type issues. (I'm running with the latest master, plus my pull request 54).
The bad news is, that seems to have unblocked me to find the next problem...
I'm running the usual stress test where I kill and restart members, and verify that the group heals itself. I've managed to get into a situation where:
- A, B, and C all have no view at all (they're all repeatedly sending JOINs that time out)
- D has got stuck with a view {B,C,D,A,C} (in which every member except D is in fact a dead instance).
So what's happening on each of A, B and C is:
- perform discovery
- decide based on information from D that the long-dead B is coordinator
- send a JOIN to that dead B
- this times out
- repeat
Meanwhile D's FD is repeatedly broadcasting that A is suspect, but no-one pays any attention.
In an ideal world, I'd think that it ought to be up to D to spot that something has gone wrong. Eg after a long enough period of reporting that A is suspect without seeing any change of view, it could deduce that there's a problem and become a singleton; or something like that. Then a merge should sort everything out in due course.
I'm actually experimenting with a workaround in which we only allow JOIN attempts to time out some maximum number of times; and if they time out too often the member becomes a singleton. ie I'm making a fix that allows A, B and C to proceed. Then I again expect a merge to sort everything out. This looks a lot easier to code up, and seems a plausible thing to want to do anyway.
I have the test running and will see how this goes overnight. If it looks to work I'll submit a pull request; else I'll think again.
--
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, 10 months
[JBoss JIRA] (AS7-4217) RemoteConnectionFactory is not found when looking up in a remote client
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-4217:
-------------------------------------
Summary: RemoteConnectionFactory is not found when looking up in a remote client
Key: AS7-4217
URL: https://issues.jboss.org/browse/AS7-4217
Project: Application Server 7
Issue Type: Bug
Components: Application Client, JMS
Affects Versions: 7.1.1.Final
Reporter: Ondřej Chaloupka
Assignee: jaikiran pai
I do lookup for RemoteConnectionFactory firstly locally in container and secondary via remote client. Then the second (remote one) lookup for RemoteConnectionFactory fails with exception:
{code}
javax.naming.NamingException: Failed to lookup [Root exception is java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.test2(LookupTestCase.java:81)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
Caused by: java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:138)
at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:128)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
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:662)
Caused by: an exception which occurred:
in field loadBalancingPolicy
in field serverLocator
in object org.hornetq.jms.client.HornetQJMSConnectionFactory@d67f82
{code}
Please check my test reproducer: https://github.com/ochaloup/jboss-as/commit/1a1605f6ad4e860789d704d682ff6...
The exception is thrown on line: https://github.com/ochaloup/jboss-as/blob/1a1605f6ad4e860789d704d682ff6e6...
Tested with standalone-full.xml. Command to run the test: ./integration-tests.sh clean install -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.*
--
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, 10 months
[JBoss JIRA] (AS7-5102) CLONE - PersistenceUnitSearch violates the JPA spec
by Alessandro Lazarotti (JIRA)
[ https://issues.jboss.org/browse/AS7-5102?page=com.atlassian.jira.plugin.s... ]
Alessandro Lazarotti deleted AS7-5102:
--------------------------------------
> CLONE - PersistenceUnitSearch violates the JPA spec
> ---------------------------------------------------
>
> Key: AS7-5102
> URL: https://issues.jboss.org/browse/AS7-5102
> Project: Application Server 7
> Issue Type: Bug
> Environment: Linux (Ubuntu, kernel v.3.0.0-12-generic), Java HotSpot SE Runtime Environment (build 1.6.0_31-b04)
> Reporter: Alessandro Lazarotti
> Assignee: Scott Marlow
>
> There is no ability to deploy EAR, which contains several EJB-JAR modules, when more then one of them defining a persistence unit and at least one of EJBs within module "expresses a dependency on a container-managed EntityManager and its associated persistence context" (e.g. using @PersistenceContext annotation) without specifying the unitName.
> Stacktrace during deployment process of such EAR:
> 13:45:36,765 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "persistence-scope-test-ear-ear.ear"
> 13:45:36,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar"
> 13:45:36,794 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar"
> 13:45:36,886 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011401: Read persistence.xml for primary
> 13:45:36,889 INFO [org.jboss.as.jpa] (MSC service thread 1-4) JBAS011401: Read persistence.xml for primary
> 13:45:36,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
> at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> 13:45:36,899 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
> at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
> at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> Issue is related to the AS7-2275 (https://issues.jboss.org/browse/AS7-2275).
> JPA 2.0 specification (in paragraph "8.2.2 Persistence Unit Scope") states that:
> "When referencing a persistence unit using the unitName annotation element or persistence-
> unit-name deployment descriptor element, the visibility scope of the persistence unit is
> determined by its point of definition:
> • A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is
> scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components
> defined in that jar or war."
> Although it says "when referencing... using the unitName", when in this case "unitName" attribute is omitted, I believe this (taking into account persistence units defined in other modules) is still a bug, cause:
> 1. The scope of a persistence unit is all the same implied by the spec, e.g. by sentences like this: "The persistence.xml file may be used to designate more than one persistence unit within the same scope. The persistence.xml file may be used to designate more than one persistence unit within the same scope."
> 2. AFAIK, neither JPA 2.0 nor EJB 3.1 specification defines any persistence unit choosing algorithm in case of unitName omission despite this attribute is optional.
> Code responsible for generating an aforementioned exception resides in org.jboss.as.jpa.container.PersistenceUnitSearch:
>
> PersistenceUnitsInApplication persistenceUnitsInApplication = DeploymentUtils.getTopDeploymentUnit(deploymentUnit).getAttachment(PersistenceUnitsInApplication.PERSISTENCE_UNITS_IN_APPLICATION);
>
> if (persistenceUnitsInApplication.getCount() > 1) {
>
> // AS7-2275 no unitName and there is more than one persistence unit;
>
> throw MESSAGES.noPUnitNameSpecifiedAndMultiplePersistenceUnits(persistenceUnitsInApplication.getCount(),DeploymentUtils.getTopDeploymentUnit(deploymentUnit));
>
> }
> So, since a developer haven't defined any EAR-level persistence unit ant tries to inject EntityManager without using the unitName - all persistence unit defined in other EJB/WAR modules are taken into account and application is prevented from deploying because of "false ambiguity".
--
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, 10 months
[JBoss JIRA] (AS7-5102) CLONE - PersistenceUnitSearch violates the JPA spec
by Alessandro Lazarotti (JIRA)
Alessandro Lazarotti created AS7-5102:
-----------------------------------------
Summary: CLONE - PersistenceUnitSearch violates the JPA spec
Key: AS7-5102
URL: https://issues.jboss.org/browse/AS7-5102
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final
Environment: Linux (Ubuntu, kernel v.3.0.0-12-generic), Java HotSpot SE Runtime Environment (build 1.6.0_31-b04)
Reporter: Alessandro Lazarotti
Assignee: Scott Marlow
Fix For: 7.2.0.Alpha1
There is no ability to deploy EAR, which contains several EJB-JAR modules, when more then one of them defining a persistence unit and at least one of EJBs within module "expresses a dependency on a container-managed EntityManager and its associated persistence context" (e.g. using @PersistenceContext annotation) without specifying the unitName.
Stacktrace during deployment process of such EAR:
13:45:36,765 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "persistence-scope-test-ear-ear.ear"
13:45:36,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar"
13:45:36,794 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar"
13:45:36,886 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011401: Read persistence.xml for primary
13:45:36,889 INFO [org.jboss.as.jpa] (MSC service thread 1-4) JBAS011401: Read persistence.xml for primary
13:45:36,898 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb2-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
13:45:36,899 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.subunit."persistence-scope-test-ear-ear.ear"."persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar".DEPENDENCIES: Failed to process phase DEPENDENCIES of subdeployment "persistence-scope-test-ear-ejb-0.0.1-SNAPSHOT.jar" of deployment "persistence-scope-test-ear-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment "persistence-scope-test-ear-ear.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
at org.jboss.as.jpa.container.PersistenceUnitSearch.resolvePersistenceUnitSupplier(PersistenceUnitSearch.java:69)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getPersistenceUnit(JPAAnnotationParseProcessor.java:284)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.getBindingSource(JPAAnnotationParseProcessor.java:220)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processField(JPAAnnotationParseProcessor.java:151)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.processPersistenceAnnotations(JPAAnnotationParseProcessor.java:118)
at org.jboss.as.jpa.processor.JPAAnnotationParseProcessor.deploy(JPAAnnotationParseProcessor.java:90)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
Issue is related to the AS7-2275 (https://issues.jboss.org/browse/AS7-2275).
JPA 2.0 specification (in paragraph "8.2.2 Persistence Unit Scope") states that:
"When referencing a persistence unit using the unitName annotation element or persistence-
unit-name deployment descriptor element, the visibility scope of the persistence unit is
determined by its point of definition:
• A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is
scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components
defined in that jar or war."
Although it says "when referencing... using the unitName", when in this case "unitName" attribute is omitted, I believe this (taking into account persistence units defined in other modules) is still a bug, cause:
1. The scope of a persistence unit is all the same implied by the spec, e.g. by sentences like this: "The persistence.xml file may be used to designate more than one persistence unit within the same scope. The persistence.xml file may be used to designate more than one persistence unit within the same scope."
2. AFAIK, neither JPA 2.0 nor EJB 3.1 specification defines any persistence unit choosing algorithm in case of unitName omission despite this attribute is optional.
Code responsible for generating an aforementioned exception resides in org.jboss.as.jpa.container.PersistenceUnitSearch:
PersistenceUnitsInApplication persistenceUnitsInApplication = DeploymentUtils.getTopDeploymentUnit(deploymentUnit).getAttachment(PersistenceUnitsInApplication.PERSISTENCE_UNITS_IN_APPLICATION);
if (persistenceUnitsInApplication.getCount() > 1) {
// AS7-2275 no unitName and there is more than one persistence unit;
throw MESSAGES.noPUnitNameSpecifiedAndMultiplePersistenceUnits(persistenceUnitsInApplication.getCount(),DeploymentUtils.getTopDeploymentUnit(deploymentUnit));
}
So, since a developer haven't defined any EAR-level persistence unit ant tries to inject EntityManager without using the unitName - all persistence unit defined in other EJB/WAR modules are taken into account and application is prevented from deploying because of "false ambiguity".
--
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, 10 months
[JBoss JIRA] (AS7-5084) Wrong text when add-user.sh adds a password for a slave HC
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5084:
-------------------------------------
Summary: Wrong text when add-user.sh adds a password for a slave HC
Key: AS7-5084
URL: https://issues.jboss.org/browse/AS7-5084
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.2.Final (EAP)
Reporter: Brian Stansberry
Assignee: Darran Lofthouse
Priority: Minor
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
About to add user 'bstansberry' for realm 'ManagementRealm'
...
Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
yes/no?
That "e.g. slave domain controller" is poorly worded. Better is "e.g. a slave host controller connecting to the master domain controller?"
Is there any other use case this question is handling? If not, let's just be simple and direct, e.g.:
"Is this new user going to be used for a slave host controller connecting to the master domain controller?"
--
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, 10 months
[JBoss JIRA] (JGRP-1488) NPE in concurrent channel creation with shared transport
by Bela Ban (JIRA)
Bela Ban created JGRP-1488:
------------------------------
Summary: NPE in concurrent channel creation with shared transport
Key: JGRP-1488
URL: https://issues.jboss.org/browse/JGRP-1488
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.10
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0.11, 3.1
The NPE below is caused by calling GET_LOCAL_ADDRESS on all up_prots in a shared transport. However, when we create a new JChannel, its protocol stack is added to up_prots *before* the top_prot (RSVP in the case below) is connected to ProtocolStack.
SOLUTION: connect the top protocol to ProtocolStack *before* connecting all protocols to each other and adding the bottom prot to up_prots in TP.
11:53:23,057 ERROR [org.jboss.msc.service.fail] (ChannelService lifecycle - 1) MSC00001: Failed to start service jboss.jgroups.channel.capedwarf: org.jboss.msc.service.StartException in service jboss.jgroups.channel.capedwarf: java.lang.NullPointerException
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:68) [jboss-as-clustering-common-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_33]
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
Caused by: java.lang.NullPointerException
at org.jgroups.protocols.RSVP.up(RSVP.java:192) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:265) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.BARRIER.up(BARRIER.java:148) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.Discovery.up(Discovery.java:499) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.TP.fetchLocalAddresses(TP.java:1529) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.TP.start(TP.java:939) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.UDP.start(UDP.java:225) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:65) [jboss-as-clustering-common-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 4 more
--
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, 10 months