[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2297:
---------------------------
Fix Version/s: 4.0.17
(was: 4.0.16)
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.17
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11616) CDIBuiltinInjectionTestCase fails with a security manager installed
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11616?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11616:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/12019
> CDIBuiltinInjectionTestCase fails with a security manager installed
> -------------------------------------------------------------------
>
> Key: WFLY-11616
> URL: https://issues.jboss.org/browse/WFLY-11616
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Brian Stansberry
> Assignee: Matej Novotny
> Priority: Major
>
> New test case in https://github.com/wildfly/wildfly/pull/11996/files fails when a security manager is present. This is a pre-existing problem not introduced by the PR. The PR is just the first test coverage we have of using @Inject Principal.
> I'll configure the test to be ignored if an s-m is present; this JIRA is to track a proper resolution.
> Details:
> {code}
> Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
> at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84)
> at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136)
> at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84)
> at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41)
> at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source)
> at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40)
> at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> ... 57 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91)
> at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49)
> at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80)
> ... 80 more
> {code}
> I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block. Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11617) Validation not working for pooled-connection-factory's transaction attribute.
by Chao Wang (Jira)
[ https://issues.jboss.org/browse/WFLY-11617?page=com.atlassian.jira.plugin... ]
Chao Wang moved JBEAP-16260 to WFLY-11617:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11617 (was: JBEAP-16260)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
Transactions
(was: JMS)
(was: Transactions)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 15.0.1.Final
(was: 7.2.0.GA)
> Validation not working for pooled-connection-factory's transaction attribute.
> ------------------------------------------------------------------------------
>
> Key: WFLY-11617
> URL: https://issues.jboss.org/browse/WFLY-11617
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 15.0.1.Final
> Reporter: varsha Kamble
> Assignee: Chao Wang
> Priority: Minor
>
> Validation not working for pooled-connection-factory's "transaction" attribute. According to xsd, it should accept only xa, local and none. However it is accepting anything.
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=transaction,value=jjj)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :relaod
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11616) CDIBuiltinInjectionTestCase fails with a security manager installed
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11616?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11616:
--------------------------------------
Spec doesn't say anything about permissions, in fact [the only thing it says around {{Principal}}|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#additional_builtin_beans] is that there is a built-in bean with {{@Default}} qualifier provided. The rest is up to integrator (which, in Weld, is done via {{WeldSecurityServices}}).
I'll send a PR adding the privileged block.
> CDIBuiltinInjectionTestCase fails with a security manager installed
> -------------------------------------------------------------------
>
> Key: WFLY-11616
> URL: https://issues.jboss.org/browse/WFLY-11616
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Brian Stansberry
> Assignee: Matej Novotny
> Priority: Major
>
> New test case in https://github.com/wildfly/wildfly/pull/11996/files fails when a security manager is present. This is a pre-existing problem not introduced by the PR. The PR is just the first test coverage we have of using @Inject Principal.
> I'll configure the test to be ignored if an s-m is present; this JIRA is to track a proper resolution.
> Details:
> {code}
> Caused by: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
> at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:84)
> at org.jboss.as.security.service.SimpleSecurityManager.getCallerPrincipal(SimpleSecurityManager.java:136)
> at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:84)
> at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:41)
> at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:30)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:38)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> at org.jboss.weld.security.Principal$$Proxy$_$$_Weld$Proxy$.getName(Unknown Source)
> at org.jboss.as.test.integration.weld.builtin.CDIResource.getMessage(CDIResource.java:40)
> at org.jboss.as.test.integration.weld.builtin.CDIResource$Proxy$_$$_WeldClientProxy.getMessage(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> ... 57 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.identity.plugins.IdentityFactory.loadClass")" in code source "(vfs:/content/cdibuiltin.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.cdibuiltin.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at org.jboss.security.identity.plugins.IdentityFactory.loadClass(IdentityFactory.java:91)
> at org.jboss.security.identity.plugins.IdentityFactory.createPrincipal(IdentityFactory.java:49)
> at org.jboss.security.identity.plugins.SimpleIdentity.asPrincipal(SimpleIdentity.java:80)
> ... 80 more
> {code}
> I don't know whether the spec has anything to say regarding any permissions that should be required in order to inject a Principal. If it says they shouldn't be required or is silent on the topic and we think they should not be necessary, then we are missing a privileged block. Otherwise I doubt what's being thrown here is what we'd want. If some permission is needed, checking for something more related to the use case (probably something new) would be better, and if that permission check passes then make the call in a privileged block.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11605) Master Artemis in Wildfly 10.1.0.Final is abruptly shutting down without a proper failback to Backup
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11605?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11605:
------------------------------------
Updated ticket to blocker as deployment with current scenario in the field leads to unstable.
Please suggest the setup for 2nd approach as discussed over documentation (Pinging the network).
> Master Artemis in Wildfly 10.1.0.Final is abruptly shutting down without a proper failback to Backup
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11605
> URL: https://issues.jboss.org/browse/WFLY-11605
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: Project component log.txt, Wildfly error abrupt failback.txt
>
>
> Scenario - Master, and Slave Running on 2 VM's.
> Master Wildfly - <replication-master cluster-name="my-cluster" group-name="srini-queues-cluster-group" check-for-live-server="true"/>
> Slave Wildfly - <replication-slave cluster-name="my-cluster" group-name="srini-queues-cluster-group" allow-failback="false" max-saved-replicated-journal-size="1"/>
> PFB below 2 errors.
> At this time Slave will start deploying Queues even when Master wildfly is not stopped completely. Both management consoles can be reached.
> Ideally, the Master server(Wildfly) should completely stop for Slave to start the deployment of queues and start the replication.
> 2019/01/16 19:56:21,118+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224044: error acknowledging message: java.lang.NullPointer
> Exception
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeReferenceByID(ServerConsumerImpl.java:811)
> 2019/01/16 19:56:21,121+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224016: Caught exception: ActiveMQIllegalStateException[er
> rorType=ILLEGAL_STATE message=null]
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.individualAcknowledge(ServerConsumerImpl.java:772)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.individualAcknowledge(ServerSessionImpl.java:739)
> Detailed logs are attached.
> At this stage, 1st component in my project pipeline has identified the slave as master now and stick with sending messages to it. Whereas the other components in the pipeline still consuming from Master(based on consumer count).
> This caused the break-in message flow.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11605) Master Artemis in Wildfly 10.1.0.Final is abruptly shutting down without a proper failback to Backup
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11605?page=com.atlassian.jira.plugin... ]
Srinivas ev updated WFLY-11605:
-------------------------------
Priority: Blocker (was: Major)
> Master Artemis in Wildfly 10.1.0.Final is abruptly shutting down without a proper failback to Backup
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11605
> URL: https://issues.jboss.org/browse/WFLY-11605
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: Project component log.txt, Wildfly error abrupt failback.txt
>
>
> Scenario - Master, and Slave Running on 2 VM's.
> Master Wildfly - <replication-master cluster-name="my-cluster" group-name="srini-queues-cluster-group" check-for-live-server="true"/>
> Slave Wildfly - <replication-slave cluster-name="my-cluster" group-name="srini-queues-cluster-group" allow-failback="false" max-saved-replicated-journal-size="1"/>
> PFB below 2 errors.
> At this time Slave will start deploying Queues even when Master wildfly is not stopped completely. Both management consoles can be reached.
> Ideally, the Master server(Wildfly) should completely stop for Slave to start the deployment of queues and start the replication.
> 2019/01/16 19:56:21,118+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224044: error acknowledging message: java.lang.NullPointer
> Exception
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeReferenceByID(ServerConsumerImpl.java:811)
> 2019/01/16 19:56:21,121+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224016: Caught exception: ActiveMQIllegalStateException[er
> rorType=ILLEGAL_STATE message=null]
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.individualAcknowledge(ServerConsumerImpl.java:772)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.individualAcknowledge(ServerSessionImpl.java:739)
> Detailed logs are attached.
> At this stage, 1st component in my project pipeline has identified the slave as master now and stick with sending messages to it. Whereas the other components in the pipeline still consuming from Master(based on consumer count).
> This caused the break-in message flow.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11549) Wildfly-14 : ClassCastException while marshalling/unmarshalling
by Bhavesh Kharwa (Jira)
[ https://issues.jboss.org/browse/WFLY-11549?page=com.atlassian.jira.plugin... ]
Bhavesh Kharwa edited comment on WFLY-11549 at 1/21/19 12:34 AM:
-----------------------------------------------------------------
its happen while redeploying.
Got error for JAXB marshalling/unmarshalling and Hibernate related below error:
{noformat}
org.springframework.integration.MessageHandlingException: org.springframework.dao.InvalidDataAccessApiUsageException: Type specified for TypedQuery [com.model.MsgRevision] is incompatible with query return type [class com.model.jpa.JpaMsgRevision]; nested exception is java.lang.IllegalArgumentException: Type specified for TypedQuery [com.model.MsgRevision] is incompatible with query return type [class com.model.jpa.JpaMsgRevision]
{noformat}
was (Author: bhavesh.rkharwa):
its happen while redeploying
> Wildfly-14 : ClassCastException while marshalling/unmarshalling
> ---------------------------------------------------------------
>
> Key: WFLY-11549
> URL: https://issues.jboss.org/browse/WFLY-11549
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 14.0.0.Final
> Reporter: Bhavesh Kharwa
> Assignee: Jason Greene
> Priority: Critical
> Attachments: hprofsnapshot.jpg
>
>
> I have configured wildfly-14 in domain mode and configured one profile "*full-ha-socket*" in domain.xml. Now I have deployed ear in wildfly.The application having functionality of marshalling/unmarshalling of content. Also I have provided jaxb dependency in maven as scope provided.
> So the issue is when I process the file the it throws classcastexception. Please refer below stackstrace.
> *Note: Sometimes it is working but sometimes giving exception*
> {code}
> Unhandled exception while procesing file 'testing.xml': java.lang.ClassCastException: com.commons.impl.NewsMessageImpl cannot be cast to com.commons.NewsMessage
> at com.common.transform.MessageTransformationService.transform(MessageTransformationService.java:521)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96cproceed(AbstractTransactionAspect.aj:59)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect$AbstractTransactionAspect$1.proceedWithInvocation(AbstractTransactionAspect.aj:65)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260)
> at org.springframework.transaction.aspectj.AbstractTransactionAspect.ajc$around$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96c(AbstractTransactionAspect.aj:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.expression.spel.support.ReflectiveMethodExecutor.execute(ReflectiveMethodExecutor.java:69)
> at org.springframework.expression.spel.ast.MethodReference.getValueInternal(MethodReference.java:122)
> at org.springframework.expression.spel.ast.MethodReference.access$000(MethodReference.java:44)
> at org.springframework.expression.spel.ast.MethodReference$MethodValueRef.getValue(MethodReference.java:258)
> at org.springframework.expression.spel.ast.CompoundExpression.getValueInternal(CompoundExpression.java:82)
> at org.springframework.expression.spel.ast.SpelNodeImpl.getTypedValue(SpelNodeImpl.java:102)
> at org.springframework.expression.spel.standard.SpelExpression.getValue(SpelExpression.java:103)
> at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:126)
> at org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:227)
> at org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:127)
> at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:73)
> at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:67)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:134)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:102)
> at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:77)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
> at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:128)
> at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
> at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendMessage(AbstractReplyProducingMessageHandler.java:216)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.sendReplyMessage(AbstractReplyProducingMessageHandler.java:200)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.produceReply(AbstractReplyProducingMessageHandler.java:165)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleResult(AbstractReplyProducingMessageHandler.java:159)
> at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:141)
> at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:73)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:115)
> at org.springframework.integration.dispatcher.UnicastingDispatcher.access$000(UnicastingDispatcher.java:52)
> at org.springframework.integration.dispatcher.UnicastingDispatcher$1.run(UnicastingDispatcher.java:97)
> at org.springframework.integration.util.ErrorHandlingTaskExecutor$1.run(ErrorHandlingTaskExecutor.java:52)
> at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)
> {code}
> Also i have added following dependencies in jboss-deployment-structure.xml
> - javax.mail.api
> - org.hibernate (slot=main)
> - javax.validation.api
> - com.sun.xml.bind (slot=main)
> - org.wildfly.clustering.singleton(slot=main)
> No duplicate classes/jars in application ear/lib...
> One thing I have noticed that if I undeploy & deploy the application then this issue start reproducing.
> One question: When I undeploy application, How can i verify application undeployed successfully (Removed all the application classes/lib from class loader while undeploy application)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months