[JBoss JIRA] (DROOLS-2667) Wrong dependency in Drools BOM
by Pino Navato (JIRA)
Pino Navato created DROOLS-2667:
-----------------------------------
Summary: Wrong dependency in Drools BOM
Key: DROOLS-2667
URL: https://issues.jboss.org/browse/DROOLS-2667
Project: Drools
Issue Type: Bug
Components: build
Affects Versions: 7.7.0.Final, 7.6.0.Final, 7.5.0.Final, 7.4.1.Final, 7.3.0.Final, 7.2.0.Final, 7.1.0.Final, 7.0.0.Final
Reporter: Pino Navato
Assignee: Ant Stephenson
Priority: Minor
Latest version of drools-simulator is 6.5.0.Final but versions of drools-bom after 6.5.0.Final reference a *not-existent* drools-simulator with the same version number of drools-bom.
This does not causes problems during normal builds but causes "mvn site" command to fail if "dependency-management" report of maven-project-info-reports-plugin is requested.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-10655) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by tommaso borgato (JIRA)
tommaso borgato created WFLY-10655:
--------------------------------------
Summary: SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
Key: WFLY-10655
URL: https://issues.jboss.org/browse/WFLY-10655
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, JSF
Reporter: tommaso borgato
Assignee: Martin Kouba
Affected scenario is eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync.
Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
{noformat}
2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
{noformat}
Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-1946) Severe error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-1946?page=com.atlassian.jira.plugin.... ]
tommaso borgato closed WFLY-1946.
---------------------------------
Resolution: Done
too old: will be opened as new issue
> Severe error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
> Key: WFLY-1946
> URL: https://issues.jboss.org/browse/WFLY-1946
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Stan Silvert
> Fix For: 9.0.0.Final
>
> Attachments: Jira-WFLY-1946.tar
>
>
> Deploy of test.ear shows a severe error:
> 00:23:21,917 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "test.ear" (runtime-name: "test.ear")
> 00:23:21,941 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "web.war")
> 00:23:21,942 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar")
> 00:23:22,080 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment test.ear
> 00:23:22,121 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment ejb.jar
> 00:23:22,141 INFO [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
> 00:23:22,157 INFO [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: test.ear
> 00:23:22,192 INFO [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment test.ear
> 00:23:22,734 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra
> 00:23:22,753 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra
> 00:23:23,099 INFO [test.web.Startup#contextInitialized] contextInitialized
> 00:23:23,405 INFO [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /intern/web
> 00:23:23,465 INFO [org.jboss.as.server#handleResult] JBAS018559: Deployed "test.ear" (runtime-name : "test.ear")
> Although everything seems to be fine. App works without errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-6405) Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
by Jan Swaelens (JIRA)
[ https://issues.jboss.org/browse/WFLY-6405?page=com.atlassian.jira.plugin.... ]
Jan Swaelens commented on WFLY-6405:
------------------------------------
[~swd847], [~kabirkhan], [~jamezp], I am seeing this on EAP 7.0 - is it fixed on a higher patch version or do you have any info in which EAP version this will be fixed as well?
> Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
> ---------------------------------------------------------------------------
>
> Key: WFLY-6405
> URL: https://issues.jboss.org/browse/WFLY-6405
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading
> Affects Versions: 10.0.0.Final
> Reporter: Panos Grigoropoulos
> Assignee: Stuart Douglas
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> (Wildfly 10.0.0.FINAL)
> During the performance test of my app (50 concurrent users with jmeter) I am running into the following issue:
> There are locked threads in the method WeldDeployment.getBeanDeploymentArchive(). Looking the code, this method is synchronized, so it makes sense. The question is, is this the expected behavior or this is a bug. In both cases is there any workaround to overcome this limitation?
> STACK TRACE:
> ....
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():73
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():93
> org.jboss.as.weld.deployment.WeldDeployment.getBeanDeploymentArchive():226
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-10654) In WFLY 13 when you deploy a simple Jar file , WFLY 13 treats the jar as the EJB and starts the "ejb" cache container.
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-10654?page=com.atlassian.jira.plugin... ]
Chao Wang moved JBEAP-14963 to WFLY-10654:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-10654 (was: JBEAP-14963)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
EJB
(was: Clustering)
(was: EJB)
Affects Version/s: 13.0.0.Final
(was: 7.1.0.GA)
> In WFLY 13 when you deploy a simple Jar file , WFLY 13 treats the jar as the EJB and starts the "ejb" cache container.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10654
> URL: https://issues.jboss.org/browse/WFLY-10654
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Deployment(from management console) of a simple Jar file in EAP 7.1.x causes the ejb cache container to start , which should not be the case .
> From EAP 7.1.x onwards @clustered annotation has been depricated and EJB application is required to start clustering , but in contradiction to this even if we deploy ant jar file (let's say ojdbc6.jar ) the container treats it as an EJB application and starts the EJB cache container as seen in the logs below :
> ~~~~
> 1,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
> 22:14:21,673 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [plohia|0] (1) [plohia]
> 22:14:21,673 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [plohia|0] (1) [plohia]
> 22:14:21,676 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000079: Channel ejb local address is plohia, physical addresses are [192.168.122.1:55200]
> 22:14:21,678 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is plohia, physical addresses are [192.168.122.1:55200]
> ~~~~
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-10654) In WFLY 13 when you deploy a simple Jar file , WFLY 13 treats the jar as the EJB and starts the "ejb" cache container.
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-10654?page=com.atlassian.jira.plugin... ]
Chao Wang reassigned WFLY-10654:
--------------------------------
Assignee: (was: Chao Wang)
> In WFLY 13 when you deploy a simple Jar file , WFLY 13 treats the jar as the EJB and starts the "ejb" cache container.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10654
> URL: https://issues.jboss.org/browse/WFLY-10654
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Final
> Reporter: Chao Wang
>
> Deployment(from management console) of a simple Jar file in EAP 7.1.x causes the ejb cache container to start , which should not be the case .
> From EAP 7.1.x onwards @clustered annotation has been depricated and EJB application is required to start clustering , but in contradiction to this even if we deploy ant jar file (let's say ojdbc6.jar ) the container treats it as an EJB application and starts the EJB cache container as seen in the logs below :
> ~~~~
> 1,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel ejb
> 22:14:21,640 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
> 22:14:21,673 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [plohia|0] (1) [plohia]
> 22:14:21,673 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [plohia|0] (1) [plohia]
> 22:14:21,676 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000079: Channel ejb local address is plohia, physical addresses are [192.168.122.1:55200]
> 22:14:21,678 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is plohia, physical addresses are [192.168.122.1:55200]
> ~~~~
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JGRP-2279) Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
by George Jiang (JIRA)
[ https://issues.jboss.org/browse/JGRP-2279?page=com.atlassian.jira.plugin.... ]
George Jiang reopened JGRP-2279:
--------------------------------
The BUG accidentally appeared in the system. A test did not show no recurrence or not.
> Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2279
> URL: https://issues.jboss.org/browse/JGRP-2279
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Environment: OS:Red Hat
> JDK:1.8
> Reporter: George Jiang
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.13
>
> Attachments: asym-ssl2.xml, jgroups-protocol.xml
>
>
> *asym parameters:*
> <ASYM_ENCRYPT encrypt_entire_message="true"
> sign_msgs="true"
> sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding"
> asym_keylength="2048"
> asym_algorithm="RSA"
> change_key_on_leave="true"/>
> *Throws the following error:*
> 2018-05-23T03:11:53,891 +2903450778 [jgroups--12467,-1491537117,1] ERROR org.jgroups.protocols.ASYM_ENCRYPT - 1: failed decrypting message from 2 (offset=0, length=1136, buf.length=1136): javax.crypto.BadPaddingException: Given final block not properly padded, headers are ASYM_ENCRYPT: [ENCRYPT version=16 bytes], TP: [cluster_name=-1491537117]
> 2018-05-23T03:11:53,893 +2903450780 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received message batch of 1 messages from 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: received secret key from keyserver 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: created 8 symmetric ciphers with secret key (16 bytes)
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received [dst:***
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] WARN org.jgroups.protocols.ASYM_ENCRYPT - 1: exception occurred decrypting message
> javax.crypto.BadPaddingException: Given final block not properly padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[sunjce_provider.jar:1.8.0_162]
> at javax.crypto.Cipher.doFinal(Cipher.java:2222) ~[?:1.8.0_171]
> at org.jgroups.protocols.Encrypt.code(Encrypt.java:365) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptChecksum(Encrypt.java:387) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt._decrypt(Encrypt.java:299) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptMessage(Encrypt.java:283) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleEncryptedMessage(Encrypt.java:242) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleUpMessage(Encrypt.java:229) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.up(Encrypt.java:155) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:143) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:129) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:197) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:277) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:262) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1203) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JGRP-2279) Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
by George Jiang (JIRA)
[ https://issues.jboss.org/browse/JGRP-2279?page=com.atlassian.jira.plugin.... ]
George Jiang commented on JGRP-2279:
------------------------------------
[^jgroups-protocol.xml]
The attachment is a complete configuration file. Please check to see if there is any problem. This BUG accidentally appeared in the system, making the jgroup present an unstable working condition. Please help us to further inspect it.
> Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2279
> URL: https://issues.jboss.org/browse/JGRP-2279
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Environment: OS:Red Hat
> JDK:1.8
> Reporter: George Jiang
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.13
>
> Attachments: asym-ssl2.xml, jgroups-protocol.xml
>
>
> *asym parameters:*
> <ASYM_ENCRYPT encrypt_entire_message="true"
> sign_msgs="true"
> sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding"
> asym_keylength="2048"
> asym_algorithm="RSA"
> change_key_on_leave="true"/>
> *Throws the following error:*
> 2018-05-23T03:11:53,891 +2903450778 [jgroups--12467,-1491537117,1] ERROR org.jgroups.protocols.ASYM_ENCRYPT - 1: failed decrypting message from 2 (offset=0, length=1136, buf.length=1136): javax.crypto.BadPaddingException: Given final block not properly padded, headers are ASYM_ENCRYPT: [ENCRYPT version=16 bytes], TP: [cluster_name=-1491537117]
> 2018-05-23T03:11:53,893 +2903450780 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received message batch of 1 messages from 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: received secret key from keyserver 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: created 8 symmetric ciphers with secret key (16 bytes)
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received [dst:***
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] WARN org.jgroups.protocols.ASYM_ENCRYPT - 1: exception occurred decrypting message
> javax.crypto.BadPaddingException: Given final block not properly padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[sunjce_provider.jar:1.8.0_162]
> at javax.crypto.Cipher.doFinal(Cipher.java:2222) ~[?:1.8.0_171]
> at org.jgroups.protocols.Encrypt.code(Encrypt.java:365) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptChecksum(Encrypt.java:387) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt._decrypt(Encrypt.java:299) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptMessage(Encrypt.java:283) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleEncryptedMessage(Encrypt.java:242) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleUpMessage(Encrypt.java:229) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.up(Encrypt.java:155) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:143) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:129) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:197) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:277) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:262) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1203) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JGRP-2279) Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
by George Jiang (JIRA)
[ https://issues.jboss.org/browse/JGRP-2279?page=com.atlassian.jira.plugin.... ]
George Jiang updated JGRP-2279:
-------------------------------
Attachment: jgroups-protocol.xml
> Error during ASYM_ENCRYPT-----exception occurred decrypting messagejavax.crypto.BadPaddingException: Given final block not properly padded
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2279
> URL: https://issues.jboss.org/browse/JGRP-2279
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Environment: OS:Red Hat
> JDK:1.8
> Reporter: George Jiang
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 4.0.13
>
> Attachments: asym-ssl2.xml, jgroups-protocol.xml
>
>
> *asym parameters:*
> <ASYM_ENCRYPT encrypt_entire_message="true"
> sign_msgs="true"
> sym_keylength="128"
> sym_algorithm="AES/ECB/PKCS5Padding"
> asym_keylength="2048"
> asym_algorithm="RSA"
> change_key_on_leave="true"/>
> *Throws the following error:*
> 2018-05-23T03:11:53,891 +2903450778 [jgroups--12467,-1491537117,1] ERROR org.jgroups.protocols.ASYM_ENCRYPT - 1: failed decrypting message from 2 (offset=0, length=1136, buf.length=1136): javax.crypto.BadPaddingException: Given final block not properly padded, headers are ASYM_ENCRYPT: [ENCRYPT version=16 bytes], TP: [cluster_name=-1491537117]
> 2018-05-23T03:11:53,893 +2903450780 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received message batch of 1 messages from 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: received secret key from keyserver 2
> 2018-05-23T03:11:53,895 +2903450782 [jgroups--12467,-1491537117,1] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 1: created 8 symmetric ciphers with secret key (16 bytes)
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] TRACE org.jgroups.protocols.TCP_NIO2 - 1: received [dst:***
> 2018-05-23T03:11:54,369 +2903451256 [jgroups--12467,-1491537117,1] WARN org.jgroups.protocols.ASYM_ENCRYPT - 1: exception occurred decrypting message
> javax.crypto.BadPaddingException: Given final block not properly padded
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) ~[sunjce_provider.jar:1.8.0_162]
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[sunjce_provider.jar:1.8.0_162]
> at javax.crypto.Cipher.doFinal(Cipher.java:2222) ~[?:1.8.0_171]
> at org.jgroups.protocols.Encrypt.code(Encrypt.java:365) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptChecksum(Encrypt.java:387) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt._decrypt(Encrypt.java:299) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.decryptMessage(Encrypt.java:283) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleEncryptedMessage(Encrypt.java:242) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.handleUpMessage(Encrypt.java:229) ~[jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Encrypt.up(Encrypt.java:155) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.ASYM_ENCRYPT.up(ASYM_ENCRYPT.java:143) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:129) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:197) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:277) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.Discovery.up(Discovery.java:262) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1203) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87) [jgroups-4.0.1.Final.jar:4.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFLY-10652) Mdb Clustered Singleton Delivery is not working
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10652?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10652 at 6/28/18 6:43 PM:
--------------------------------------------------------------
MdbDeliveryDependenciesProcessor should be changed to depend on CLUSTERED_SINGLETON_CAPABILITY.getCapabilityServiceName().
The recent changes to the singleton service API changed the internal service names such that usage like this can rely only on well known service names.
It looks like the lack of a test allowed this regression to go unnoticed.
was (Author: pferraro):
MdbDeliveryDependenciesProcessor should be changed to depend on CLUSTERED_SINGLETON_CAPABILITY.getCapabilityServiceName().
> Mdb Clustered Singleton Delivery is not working
> ------------------------------------------------
>
> Key: WFLY-10652
> URL: https://issues.jboss.org/browse/WFLY-10652
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Fix For: 14.0.0.CR1
>
>
> When trying to deploy an application with clustered singleton MDB delivery, we see this error:
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.ejb3.clustered.singleton"],"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"messaging-clustering-singleton.war\".clustered.singleton.dependency is missing [org.wildfly.ejb3.clustered.singleton]"]}}}
> The clustered singleton service is not being installed with the expected name.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months