[JBoss JIRA] (WFLY-4158) The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4158?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4158:
---------------------------------
Assignee: Stuart Douglas (was: Tomaz Cerar)
XNIO options are properly configured.
Also I am not sure where 30 seconds comes from as defaults we force in IO subsystem for workers is 60.
> The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4158
> URL: https://issues.jboss.org/browse/WFLY-4158
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008, Windows 7, Java SE 7u72 and 8u25 64bit
> Reporter: Raul Guerrero Deschamps
> Assignee: Stuart Douglas
> Labels: asynchronous, servlet, timeout
>
> I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
> To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default" task-keepalive="3600"/>
> <buffer-pool name="default"/>
> </subsystem>
> {code}
> And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:1.2">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="0"/>
> ...
> {code}
> Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
> {noformat}
> ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
> Followed by:
> ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
> {noformat}
> Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
> Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4236) vault.bat doesn't work with JDK 9-ea
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4236?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4236:
-----------------------------------
There are known problems with running wildfly on JDK9-EA (jigsaw builds)
We are working on fixing this together with oracle, but for now this is not high priority task
> vault.bat doesn't work with JDK 9-ea
> ------------------------------------
>
> Key: WFLY-4236
> URL: https://issues.jboss.org/browse/WFLY-4236
> Project: WildFly
> Issue Type: Sub-task
> Components: Security
> Affects Versions: 9.0.0.Beta1
> Environment: Windows 8.1, JDK 9-ea build 44
> Reporter: Juergen Zimmermann
> Assignee: Tomaz Cerar
>
> I compiled the current WildFly snapshot with JDK 8u25 on Windows 8.1 box. To configure the vault (for the database password) I switched to JDK 9 (early access, build 44). Then I created a keystore which can be listed:
> {code}
> C:\>keytool -list -v -storetype jceks -keystore C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\standalone\configuration\vault\vault.jceks -storepass <mypwd>
> Keystore-Typ: JCEKS
> Keystore-Provider: SunJCE
> Keystore enthält 1 Eintrag
> Aliasname: vault
> Erstellungsdatum: 09.01.2015
> Eintragstyp: SecretKeyEntry
> *******************************************
> *******************************************
> {code}
> Then I invoked vault.bat, which was failing:
> {code}
> C:\>SET VAULT_DIR=C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault
> C:\>vault.bat -k %VAULT_DIR%/vault.jceks -a db-pass -x p -s ABCD1234 -p <mypwd> -e %VAULT_DIR%/
> =========================================================================
> JBoss Vault Tool
> JBOSS_HOME: "C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107"
> JAVA: "C:\Zimmermann\Java\jdk\bin\java"
> JAVA_OPTS: ""
> =========================================================================
> Problem occurred:
> java.lang.Exception: WFLYSEC0045: Exception encountered:
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:192)
> at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:210)
> at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
> at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
> 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.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:483)
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:189)
> ... 9 more
> Caused by: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:691)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:205)
> ... 10 more
> Caused by: java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector from [Module "org.picketbox:main" from local module loader @3e77a1ed (finder: local module finder @3ffcd140 (roots: C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules,C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules\system\layers\base))]
> at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:842)
> at java.security.KeyStore.load(KeyStore.java:1446)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:201)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:151)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:688)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4236) vault.bat doesn't work with JDK 9-ea
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4236?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4236:
------------------------------
Parent: WFLY-3854
Issue Type: Sub-task (was: Bug)
> vault.bat doesn't work with JDK 9-ea
> ------------------------------------
>
> Key: WFLY-4236
> URL: https://issues.jboss.org/browse/WFLY-4236
> Project: WildFly
> Issue Type: Sub-task
> Components: Security
> Affects Versions: 9.0.0.Beta1
> Environment: Windows 8.1, JDK 9-ea build 44
> Reporter: Juergen Zimmermann
> Assignee: Tomaz Cerar
>
> I compiled the current WildFly snapshot with JDK 8u25 on Windows 8.1 box. To configure the vault (for the database password) I switched to JDK 9 (early access, build 44). Then I created a keystore which can be listed:
> {code}
> C:\>keytool -list -v -storetype jceks -keystore C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\standalone\configuration\vault\vault.jceks -storepass <mypwd>
> Keystore-Typ: JCEKS
> Keystore-Provider: SunJCE
> Keystore enthält 1 Eintrag
> Aliasname: vault
> Erstellungsdatum: 09.01.2015
> Eintragstyp: SecretKeyEntry
> *******************************************
> *******************************************
> {code}
> Then I invoked vault.bat, which was failing:
> {code}
> C:\>SET VAULT_DIR=C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault
> C:\>vault.bat -k %VAULT_DIR%/vault.jceks -a db-pass -x p -s ABCD1234 -p <mypwd> -e %VAULT_DIR%/
> =========================================================================
> JBoss Vault Tool
> JBOSS_HOME: "C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107"
> JAVA: "C:\Zimmermann\Java\jdk\bin\java"
> JAVA_OPTS: ""
> =========================================================================
> Problem occurred:
> java.lang.Exception: WFLYSEC0045: Exception encountered:
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:192)
> at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:210)
> at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
> at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
> 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.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:483)
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:189)
> ... 9 more
> Caused by: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:691)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:205)
> ... 10 more
> Caused by: java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector from [Module "org.picketbox:main" from local module loader @3e77a1ed (finder: local module finder @3ffcd140 (roots: C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules,C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules\system\layers\base))]
> at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:842)
> at java.security.KeyStore.load(KeyStore.java:1446)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:201)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:151)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:688)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4236) vault.bat doesn't work with JDK 9-ea
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4236?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4236:
---------------------------------
Assignee: Tomaz Cerar (was: Darran Lofthouse)
> vault.bat doesn't work with JDK 9-ea
> ------------------------------------
>
> Key: WFLY-4236
> URL: https://issues.jboss.org/browse/WFLY-4236
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.Beta1
> Environment: Windows 8.1, JDK 9-ea build 44
> Reporter: Juergen Zimmermann
> Assignee: Tomaz Cerar
>
> I compiled the current WildFly snapshot with JDK 8u25 on Windows 8.1 box. To configure the vault (for the database password) I switched to JDK 9 (early access, build 44). Then I created a keystore which can be listed:
> {code}
> C:\>keytool -list -v -storetype jceks -keystore C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\standalone\configuration\vault\vault.jceks -storepass <mypwd>
> Keystore-Typ: JCEKS
> Keystore-Provider: SunJCE
> Keystore enthält 1 Eintrag
> Aliasname: vault
> Erstellungsdatum: 09.01.2015
> Eintragstyp: SecretKeyEntry
> *******************************************
> *******************************************
> {code}
> Then I invoked vault.bat, which was failing:
> {code}
> C:\>SET VAULT_DIR=C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault
> C:\>vault.bat -k %VAULT_DIR%/vault.jceks -a db-pass -x p -s ABCD1234 -p <mypwd> -e %VAULT_DIR%/
> =========================================================================
> JBoss Vault Tool
> JBOSS_HOME: "C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107"
> JAVA: "C:\Zimmermann\Java\jdk\bin\java"
> JAVA_OPTS: ""
> =========================================================================
> Problem occurred:
> java.lang.Exception: WFLYSEC0045: Exception encountered:
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:192)
> at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:210)
> at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
> at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
> 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.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:483)
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
> at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:189)
> ... 9 more
> Caused by: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:691)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:205)
> ... 10 more
> Caused by: java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector from [Module "org.picketbox:main" from local module loader @3e77a1ed (finder: local module finder @3ffcd140 (roots: C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules,C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules\system\layers\base))]
> at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:842)
> at java.security.KeyStore.load(KeyStore.java:1446)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:201)
> at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:151)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:688)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4158) The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4158?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4158:
------------------------------
Description:
I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
{code:xml}
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="default" task-keepalive="3600"/>
<buffer-pool name="default"/>
</subsystem>
{code}
And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
{code:xml}
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" max-post-size="0"/>
...
{code}
Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
{noformat}
ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
Followed by:
ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
{noformat}
Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
was:
I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="default" task-keepalive="3600"/>
<buffer-pool name="default"/>
</subsystem>
And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" max-post-size="0"/>
...
Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
Followed by:
ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
> The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4158
> URL: https://issues.jboss.org/browse/WFLY-4158
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008, Windows 7, Java SE 7u72 and 8u25 64bit
> Reporter: Raul Guerrero Deschamps
> Assignee: Tomaz Cerar
> Labels: asynchronous, servlet, timeout
>
> I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
> To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default" task-keepalive="3600"/>
> <buffer-pool name="default"/>
> </subsystem>
> {code}
> And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:1.2">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="0"/>
> ...
> {code}
> Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
> {noformat}
> ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
> Followed by:
> ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
> {noformat}
> Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
> Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4236) vault.bat doesn't work with JDK 9-ea
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-4236:
----------------------------------------
Summary: vault.bat doesn't work with JDK 9-ea
Key: WFLY-4236
URL: https://issues.jboss.org/browse/WFLY-4236
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 9.0.0.Beta1
Environment: Windows 8.1, JDK 9-ea build 44
Reporter: Juergen Zimmermann
Assignee: Darran Lofthouse
I compiled the current WildFly snapshot with JDK 8u25 on Windows 8.1 box. To configure the vault (for the database password) I switched to JDK 9 (early access, build 44). Then I created a keystore which can be listed:
{code}
C:\>keytool -list -v -storetype jceks -keystore C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\standalone\configuration\vault\vault.jceks -storepass <mypwd>
Keystore-Typ: JCEKS
Keystore-Provider: SunJCE
Keystore enthält 1 Eintrag
Aliasname: vault
Erstellungsdatum: 09.01.2015
Eintragstyp: SecretKeyEntry
*******************************************
*******************************************
{code}
Then I invoked vault.bat, which was failing:
{code}
C:\>SET VAULT_DIR=C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault
C:\>vault.bat -k %VAULT_DIR%/vault.jceks -a db-pass -x p -s ABCD1234 -p <mypwd> -e %VAULT_DIR%/
=========================================================================
JBoss Vault Tool
JBOSS_HOME: "C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107"
JAVA: "C:\Zimmermann\Java\jdk\bin\java"
JAVA_OPTS: ""
=========================================================================
Problem occurred:
java.lang.Exception: WFLYSEC0045: Exception encountered:
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:192)
at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:210)
at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
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.modules.Module.run(Module.java:308)
at org.jboss.modules.Main.main(Main.java:483)
Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210)
at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:189)
... 9 more
Caused by: java.lang.RuntimeException: PBOX000140: Unable to get keystore (C:/Zimmermann/wildfly-9.0.0.Alpha2-20150107/standalone/configuration/vault/vault.jceks)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:691)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:205)
... 10 more
Caused by: java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector from [Module "org.picketbox:main" from local module loader @3e77a1ed (finder: local module finder @3ffcd140 (roots: C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules,C:\Zimmermann\wildfly-9.0.0.Alpha2-20150107\modules\system\layers\base))]
at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:842)
at java.security.KeyStore.load(KeyStore.java:1446)
at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:201)
at org.picketbox.util.KeyStoreUtil.getKeyStore(KeyStoreUtil.java:151)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.getKeyStore(PicketBoxSecurityVault.java:688)
... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:12 AM:
-------------------------------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing in WildFly 9:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
was (Author: pferraro):
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:09 AM:
-------------------------------------------------------------
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web" using channel "ee".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC via its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist for its "ee" channel, triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web" using channel "ee".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
was (Author: pferraro):
Hey Bela, I need to boost the priority of this...
Infinispan 7.0.3 made a change that results in an immediate RPC on view change.
https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9...
Here's what I'm seeing:
# Node 1 starts.
# Node 1 creates and connects channel "ee".
# Node 1 creates fork channel "web".
# Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# Node 2 starts.
# Node 2 creates and connects its "ee" channel.
# The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel
# The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event):
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP...
... since, in this case, get(hdr.getForkChannelId()) returns null.
# Node 2 creates fork channel "web".
# Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache.
# The RPC initiated on Node 1 times out waiting for responses.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated JGRP-1905:
-------------------------------
Issue Type: Bug (was: Enhancement)
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months