[JBoss JIRA] (WFLY-5874) Some JPA compat tests fail with security manager
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5874?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5874:
------------------------------------
I will create a HHH jira for the Hibernate issue and update the description of WFLY-5874 to be for the EclipseLink test change (since there are no WildFly changes to make for the Hibernate HHH issue reported on WFLY-5874).
> Some JPA compat tests fail with security manager
> ------------------------------------------------
>
> Key: WFLY-5874
> URL: https://issues.jboss.org/browse/WFLY-5874
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate, Test Suite
> Reporter: Ondrej Kotek
> Assignee: Scott Marlow
>
> *EclipseLinkSharedModuleProviderTestCase#testSimpleCreateAndLoadEntities*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.compat -Dts.noSmoke -Dtest=org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase#testSimpleCreateAndLoadEntities}}
> fails with:
> {noformat}
> javax.ejb.EJBException: javax.persistence.PersistenceException: Exception [EclipseLink-28019] (Eclipse Persistence Services - 2.6.0.v20150309-bf26070): org.eclipse.persistence.exceptions.EntityManagerSetupException
> Exception Description: Deployment of PersistenceUnit [hibernate3_pc] failed. Close all factories for this PersistenceUnit.
> Internal Exception: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/toplink_module_test.ear/beans.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.checkMemberAccess(Class.java:2348)
> at java.lang.Class.getDeclaredMethods(Class.java:1974)
> at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getDeclaredMethods(PrivilegedAccessHelper.java:339)
> at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListenerMetadata.getDeclaredMethods(EntityListenerMetadata.java:249)
> at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityClassListenerMetadata.process(EntityClassListenerMetadata.java:89)
> at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processListeners(EntityAccessor.java:1226)
> at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.addEntityListeners(MetadataProcessor.java:140)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:634)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:337)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:303)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getOrCreateTransactionScopedEntityManager(TransactionScopedEntityManager.java:157)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:87)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at org.jboss.as.test.compat.jpa.eclipselink.SFSB1.createEmployee(SFSB1.java:44)
> {noformat}
> *HibernateJarsInDeploymentTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.compat -Dts.noSmoke -Dtest=org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase}}
> fails with:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.persistenceunit."HibernateJarsInDeploymentTestCase.ear/beans.jar#hibernate_pc".__FIRST_PHASE__: org.jboss.msc.service.StartException in service jboss.persistenceunit."HibernateJarsInDeploymentTestCase.ear/beans.jar#hibernate_pc".__FIRST_PHASE__: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/HibernateJarsInDeploymentTestCase.ear/lib/hibernate-core.jar <no signer certificates>)" of "null")
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:120)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:102)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1.run(PhaseOnePersistenceUnitServiceImpl.java:129)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/HibernateJarsInDeploymentTestCase.ear/lib/hibernate-core.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:335)
> at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
> at java.lang.ClassLoader.<init>(ClassLoader.java:316)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.<init>(ClassLoaderServiceImpl.java:164)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.<init>(ClassLoaderServiceImpl.java:160)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.<init>(ClassLoaderServiceImpl.java:94)
> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:206)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:161)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:144)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:28)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:40)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:39)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:159)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:242)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:59)
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:117)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JASSIST-257) java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugi... ]
Shigeru Chiba edited comment on JASSIST-257 at 1/12/16 9:51 AM:
----------------------------------------------------------------
Hmm... it's a mistake during the release process.
I've recompiled the source by Java 6 compiler and uploaded it to github.
Download javassist.jar from [github|https://github.com/jboss-javassist/javassist].
Or download the source from the same site and build by yourself.
Just run "ant jar"
was (Author: chiba):
Hmm... it's a mistake during the release process.
I recompiled the source by Java 6 compiler and upload it to github.
Download javassist.jar from [github|https://github.com/jboss-javassist/javassist].
Or download the source from the same site and build by yourself.
Just run "ant jar"
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> --------------------------------------------------------------------------------------------------
>
> Key: JASSIST-257
> URL: https://issues.jboss.org/browse/JASSIST-257
> Project: Javassist
> Issue Type: Release
> Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5
> Javassist version 3.20.0-GA
> Reporter: Simon Franquet
> Assignee: Shigeru Chiba
>
> Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class transformation fails with the this :
> Redefinition class failed !
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33)
> at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
> at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
> at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143)
> at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JASSIST-257) java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-257:
---------------------------------------
Hmm... it's a mistake during the release process.
I recompiled the source by Java 6 compiler and upload it to github.
Download javassist.jar from [github|https://github.com/jboss-javassist/javassist].
Or download the source from the same site and build by yourself.
Just run "ant jar"
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> --------------------------------------------------------------------------------------------------
>
> Key: JASSIST-257
> URL: https://issues.jboss.org/browse/JASSIST-257
> Project: Javassist
> Issue Type: Release
> Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5
> Javassist version 3.20.0-GA
> Reporter: Simon Franquet
> Assignee: Shigeru Chiba
>
> Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class transformation fails with the this :
> Redefinition class failed !
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33)
> at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
> at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
> at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143)
> at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5975) @RequestScoped context lost in @Asynchonous calls
by Iaroslav Savytskyi (JIRA)
[ https://issues.jboss.org/browse/WFLY-5975?page=com.atlassian.jira.plugin.... ]
Iaroslav Savytskyi edited comment on WFLY-5975 at 1/12/16 9:25 AM:
-------------------------------------------------------------------
[~swd847], thanks for response. Stuart, what is the proper way to propagate data to new request scope? Is it possible to some how fill it? E.g. security context should be the same, etc.
Thank you.
was (Author: yaroska):
[~swd847], thanks for response. Stuart what is the proper way to propagate data to new request scope? Is it possible to some how fill it? E.g. security context should be the same, etc.
Thank you.
> @RequestScoped context lost in @Asynchonous calls
> -------------------------------------------------
>
> Key: WFLY-5975
> URL: https://issues.jboss.org/browse/WFLY-5975
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.2.Final
> Reporter: Iaroslav Savytskyi
> Assignee: Stuart Douglas
> Attachments: async_req_test.7z
>
>
> According to CDI spec 1.2 ( http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context) request scope should be active during any async calls. But in fact for every thread new request scope created and original data are lost.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5979) Colocated Artemis backup does not failback
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-5979:
---------------------------------
Summary: Colocated Artemis backup does not failback
Key: WFLY-5979
URL: https://issues.jboss.org/browse/WFLY-5979
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.CR5
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Use case:
* starts 2 WildFly servers with the standalone-full-ha.xml configuration and additional ha-policy for the messaging-activemq server:
{noformat}
<replication-colocated request-backup="true">
<master check-for-live-server="true"/>
</replication-colocated>
{noformat}
The default configuration for the colocated's slave is (allow-failback=true, restart-backup=true).
Scenario:
1. Starts the 2 servers
2. Kill server #1
=> server #2 must activate its backup
3. Restart server #1
=> server #1 checks for a live server
=> server #2 must failback and restart the server #1's backup
=> server #1 is the live server
Currently at step (3), the activated server on #2 does not failback, the server #1 is started as live server and both uses the same nodeID.
{noformat}
* start server #1
14:54:12,151 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221007: Server is now live
14:54:12,151 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67]
* Server #2
14:56:27,926 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221007: Server is now live
14:56:27,927 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=198586c5-b933-11e5-a199-4dbe14260a82]
...
14:56:32,245 INFO [org.apache.activemq.artemis.core.server] (default I/O-5) AMQ221049: Activating Replica for node: cd605092-b933-11e5-ba21-cb5e13c1ea67
* Server #1 also creates a replica for server #2
14:56:32,969 INFO [org.apache.activemq.artemis.core.server] (default I/O-13) AMQ221049: Activating Replica for node: 198586c5-b933-11e5-a199-4dbe14260a82
...
14:56:32,738 INFO [org.apache.activemq.artemis.core.server] (Thread-7 (ActiveMQ-client-netty-threads-1157501840)) AMQ221024: Backup server ActiveMQServerImpl::
serverUUID=cd605092-b933-11e5-ba21-cb5e13c1ea67 is synchronized with live-server.
* Kill server #1 -> colocated backup on server #2 becomes live
14:57:21,718 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221037: ActiveMQServerImpl::serverUUID=cd605092-b933-11e5-ba21-cb5e13c1ea67 to become 'live'
* Restart server #1
15:12:05,755 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.1.0.wildfly-010 [nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67]
* At this stage both server #1 and #2 behave like live servers for cd605092
4:58:09,893 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have
a backup node active at the same time as its live node. nodeID=cd605092-b933-11e5-ba21-cb5e13c1ea67
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1812.
--------------------------
Resolution: Won't Fix
If you think this is a real bug, and not just a transient error, feel free to reopen in 3.6.8. Closing for now. Also, the shared transport has been deprecated and will get removed in 4.0.
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
> Key: JGRP-1812
> URL: https://issues.jboss.org/browse/JGRP-1812
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.14
> Environment: RHEL, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1817) OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1817?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1817.
--------------------------
Resolution: Won't Fix
If you think this is a real bug, and not just a transient error, feel free to reopen in 3.6.8. Closing for now.
> OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
> ------------------------------------------------------------------------------------
>
> Key: JGRP-1817
> URL: https://issues.jboss.org/browse/JGRP-1817
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> This test does the following:
> - creates three channels a,b,c
> - injects views
> {noformat}
> A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C}
> {noformat}
> - calls MERGE.sendMergeSolicitation() on channel A to simulate the calling of the periodic task MERGE.findSubgroupsTask which should find all views of all reachable members, check if there are different views, and if there are prepare and send a MERGE event up to GMS
> - checks that all channels have the final view of size 3
> The test fails intermittently but frequently on RHEL, with the same failure each time:
> {noformat}
> -------------------------------------------------------------------
> GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
> -------------------------------------------------------------------
> ------------- testSameCreatorDifferentIDs -----------
> [A] view=[A|5] [A]
> [B] view=[A|6] [A, B]
> [C] view=[A|7] [A, B, C]
> A's view: [A|5] [A]
> B's view: [A|6] [A, B]
> C's view: [A|7] [A, B, C]
> Enabling TRACE debugging for GMS, MERGE2 and Discovery
> ==== triggering merge solicitation ====:
> 212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
> 212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
> 212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
> 215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
> 215539 [TRACE] MERGE2: - Discovery results:
> [B]: view_id=[A|6] ([A|6] [A, B])
> [A]: view_id=[A|5] ([A|5] [A])
> 215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
> Discovery results:
> [B]: coord=A
> [A]: coord=A
> ==== checking views after merge ====:
> ....................Disabling TRACE debugging for GMS, MERGE2 and Discovery
> A's view: [A|7] [A, B]
> B's view: [A|7] [A, B]
> C's view: [A|7] [A, B, C]
> {noformat}
> Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
>
> Also, the discovery requests are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1801.
--------------------------
Resolution: Out of Date
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
