[JBoss JIRA] (WFLY-4985) bouncycastle encrypt/decrypt failed
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-4985?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-4985.
------------------------------------
Resolution: Out of Date
We have had a lot of changes since WildFly 9 - the handling of security and provider registration has been completely overhauled since then.
I would suggest testing against a later WildFly release.
A reproducer that we can also just build and deploy would also be great as presently from the current steps we need to start manually creating a test project.
> bouncycastle encrypt/decrypt failed
> -----------------------------------
>
> Key: WFLY-4985
> URL: https://issues.jboss.org/browse/WFLY-4985
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.Final
> Reporter: Orwen Xiang
> Assignee: Darran Lofthouse
> Priority: Major
>
> A war application with bouncycastle jar algorithm PBEWITHMD5AND256BITAES-CBC-OPENSSL encrypt failed
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
by jaikiran pai (Jira)
[ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin... ]
jaikiran pai commented on WFLY-11691:
-------------------------------------
>In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread 1 has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it.
I highly suspect that the fix that [~swd847] did for https://issues.jboss.org/browse/UNDERTOW-1486 will solve this part of the problem. My minimal investigation into this issue had led me to suspect that the open listener was being triggered twice in this case. Stuart notes the same thing in that other JIRA:
> This was caused by a bug in the ALPN open listener that could be triggered if the server was configured with HTTP/2 enabled but did not have the correct SSL config for HTTP/2.
This fits the issue being seen the linked forum thread where the user had HTTP2 enabled but didn't have the correct SSL config (cipher suites that weren't valid).
With this underlying issue fixed, I think the only part that needs a decision is whether the WildFly Undertow subsystem should default to something other than 60 seconds for the no-request-timeout. I don't know if that question will even be relevant now that the underlying issue with active requests being considered inactive is (I think) now solved.
> Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-11691
> URL: https://issues.jboss.org/browse/WFLY-11691
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
> Priority: Major
>
> More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly.
> In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it.
> In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup.
> [1] https://developer.jboss.org/thread/279379
> [2] https://developer.jboss.org/thread/279261
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4335) null file is created in bin directory when starting standalone.bat
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFCORE-4335?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-4335:
----------------------------------
Affects Version/s: 8.0.0.Beta3
> null file is created in bin directory when starting standalone.bat
> ------------------------------------------------------------------
>
> Key: WFCORE-4335
> URL: https://issues.jboss.org/browse/WFCORE-4335
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Beta3
> Reporter: Marek Kopecký
> Assignee: Teresa Miyar
> Priority: Critical
>
> When starting standalone.bat on Windows, a file named "null" is created in the bin directory.
> Looking at the standalone.bat file, I find this new line which was added:
> rem Remove the gc.log file from the -version check
> del /F /Q "%JBOSS_LOG_DIR%\gc.log" > null 2>&1
> But, this is a typo. What it's trying to do is suppress the output of the del command. In unix, you'd redirect it to /dev/null. In Windows, you're supposed to redirect it to nul (with one L), as in this example line from slightly earlier in the standalone.bat file:
> move /y "%JBOSS_LOG_DIR%\gc.log" "%JBOSS_LOG_DIR%\backupgc.log" > nul 2>&1
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4335) null file is created in bin directory when starting standalone.bat
by Marek Kopecký (Jira)
Marek Kopecký created WFCORE-4335:
-------------------------------------
Summary: null file is created in bin directory when starting standalone.bat
Key: WFCORE-4335
URL: https://issues.jboss.org/browse/WFCORE-4335
Project: WildFly Core
Issue Type: Bug
Components: Scripts
Reporter: Marek Kopecký
Assignee: Teresa Miyar
When starting standalone.bat on Windows, a file named "null" is created in the bin directory.
Looking at the standalone.bat file, I find this new line which was added:
rem Remove the gc.log file from the -version check
del /F /Q "%JBOSS_LOG_DIR%\gc.log" > null 2>&1
But, this is a typo. What it's trying to do is suppress the output of the del command. In unix, you'd redirect it to /dev/null. In Windows, you're supposed to redirect it to nul (with one L), as in this example line from slightly earlier in the standalone.bat file:
move /y "%JBOSS_LOG_DIR%\gc.log" "%JBOSS_LOG_DIR%\backupgc.log" > nul 2>&1
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11734) Weld subsystem throws NPE deploying an application if transactions subsystem is missing
by Yeray Borges (Jira)
Yeray Borges created WFLY-11734:
-----------------------------------
Summary: Weld subsystem throws NPE deploying an application if transactions subsystem is missing
Key: WFLY-11734
URL: https://issues.jboss.org/browse/WFLY-11734
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 16.0.0.Beta1
Reporter: Yeray Borges
Assignee: Yeray Borges
The reproduction is pretty simple using Galleon. If we generate a server provisioned only with CDI and try to deploy a simple CDI application, we will get the following exception:
{noformat}
09:29:27,420 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."cdi-test-1.0.war".WeldBootstrapService: org.jboss.msc.service.StartException in service jboss.deployment.unit."cdi-test-1.0.war".WeldBootstrapService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.jboss.as.weld.WeldBootstrapService.start(WeldBootstrapService.java:127)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
... 6 more
09:29:27,424 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "cdi-test-1.0.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"cdi-test-1.0.war\".WeldBootstrapService" => "Failed to start service
Caused by: java.lang.NullPointerException"}}
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11728) Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous.
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-11728?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFLY-11728:
--------------------------------------
FYI: Microprofile dependency in test application is workaround for WFLY-11508:
{code:xml}
<manifestEntries>
<Dependencies>org.eclipse.microprofile.restclient</Dependencies>
</manifestEntries>
{code}
> Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous.
> ----------------------------------------------------------------------------
>
> Key: WFLY-11728
> URL: https://issues.jboss.org/browse/WFLY-11728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 15.0.1.Final
> Reporter: Andrej Petras
> Assignee: Alessio Soldano
> Priority: Critical
> Labels: Microprofile, resteasy-client
>
> {noformat}
> 09:35:25,936 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: Failed to start service
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec]
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.Validator.validateBeanName(Validator.java:653)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:121)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:119)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 09:35:25,941 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"mp-client-1.0.0-SNAPSHOT.war\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec]"}}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2299:
---------------------------
Fix Version/s: 4.0.19
(was: 4.0.18)
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.19
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (JGRP-2311) tshark/wireshark support
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2311?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2311:
---------------------------
Fix Version/s: 4.0.19
(was: 4.0.18)
> tshark/wireshark support
> ------------------------
>
> Key: JGRP-2311
> URL: https://issues.jboss.org/browse/JGRP-2311
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.19
>
> Attachments: tshark-convert.py
>
>
> 1. Dump contents of wireshark/tahsrk/tcpdump-generated (PCAP) files (using {{ParseMessages}}
> 2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages
> In the second instantiation, ParseMessages would read packets from stdin.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2320:
---------------------------
Fix Version/s: 4.0.19
(was: 4.0.18)
> FILE_PING.findMembers() optimizations
> -------------------------------------
>
> Key: JGRP-2320
> URL: https://issues.jboss.org/browse/JGRP-2320
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.16, 4.0.15
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.19
>
>
> Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified.
> 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter.
> To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null.
> 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months