[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-4037:
------------------------------------
Can you try to reproduce this with WF 9.0.0.Alpha1? There were significant changes made to batching/transactions with Infinispan since 8.1.
If the requisite clustering modules are available, SSO will be backed by infinispan, but non-clustered.
> Error 500 accessing png,css, rest
> ---------------------------------
>
> Key: WFLY-4037
> URL: https://issues.jboss.org/browse/WFLY-4037
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Marcial Atiénzar Navarro
> Assignee: Paul Ferraro
> Priority: Critical
>
> I've this error:
> {code}
> 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.CacheImpl.get(CacheImpl.java:369)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
> at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
> at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet moved WFLY-122 to WFCORE-213:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-213 (was: WFLY-122)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Alpha11
1.0.0.Beta1
(was: 9.0.0.Beta1)
> Clean unreferenced items from the content repository
> ----------------------------------------------------
>
> Key: WFCORE-213
> URL: https://issues.jboss.org/browse/WFCORE-213
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Alpha11, 1.0.0.Beta1
>
>
> The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example:
> 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed.
> 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed.
> Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin... ]
Tomas Remes updated WFCORE-212:
-------------------------------
Attachment: test-jms.zip
> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-212
> URL: https://issues.jboss.org/browse/WFCORE-212
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0.0.Alpha9
> Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
> Reporter: Tomas Remes
> Assignee: Jason Greene
> Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
> <activation-config-property>
> <activation-config-property-name>subscriptionDurability</activation-config-property-name>
> <activation-config-property-value>Durable</activation-config-property-value>
> </activation-config-property>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
by Tomas Remes (JIRA)
Tomas Remes created WFCORE-212:
----------------------------------
Summary: java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
Key: WFCORE-212
URL: https://issues.jboss.org/browse/WFCORE-212
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 1.0.0.Alpha9
Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
Reporter: Tomas Remes
Assignee: Jason Greene
Following steps to reproduce section you will encounter this exception:
{noformat}
15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
{noformat}
Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
{noformat}
<activation-config-property>
<activation-config-property-name>subscriptionDurability</activation-config-property-name>
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit
by Marek Goldmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.... ]
Marek Goldmann commented on WFLY-4044:
--------------------------------------
I tried to reproduce this issue, but I cannot. I used a fresh system and installed wildfly. Everything works as advertised :)
Please note that WildFly should never be started by hand when installed this way. This can cause permission issues (especially if you run it as root).
Does {{/var/log/wildfly/standalone/server.log}} say anything after you run {{systemctl start wildfly}}? What does {{journalctl -u wildfly}} say?
> Wildfly service will not start on fedora 20 - 64 bit
> ----------------------------------------------------
>
> Key: WFLY-4044
> URL: https://issues.jboss.org/browse/WFLY-4044
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.1.0.Final
> Environment: Fedora 20 - updates installed
> Reporter: Karl Nicholas
> Assignee: Marek Goldmann
>
> standalone.sh starts wildfly ok but systemctl start service fails:
> [root@localhost system]# yum install wildfly
> Loaded plugins: langpacks, refresh-packagekit
> Package wildfly-8.1.0-3.fc20.noarch already installed and latest version
> Nothing to do
> [root@localhost system]# systemctl start wildfly
> [root@localhost system]# systemctl status wildfly
> wildfly.service - The WildFly Application Server
> Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled)
> Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago
> Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE)
> Main PID: 7658 (code=exited, status=1/FAILURE)
> Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server.
> Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE
> Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state.
> [root@localhost system]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1897:
--------------------------------
I'm afraid you did ... :-) I don't mean to be a PITA, but your formatting essentially changed all lines in {{ENCRYPT}} ! Please keep the existing formatting and submit only the changes.
> ENCRYPT might drop messages during key change
> ---------------------------------------------
>
> Key: JGRP-1897
> URL: https://issues.jboss.org/browse/JGRP-1897
> Project: JGroups
> Issue Type: Bug
> Reporter: Tero Leppikangas
> Assignee: Bela Ban
> Fix For: 3.6.1
>
>
> ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed.
> This problem was noticed while doing some stress testing on the fix for JGRP-1893.
> When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted.
> We thought of possible solutions to be.
> 1. Sender specific queue holding the messages received.
> 2. Starting to queue up messages until new view has been received
> I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change.
> I wonder if there is another way to overcome this problem?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-210:
------------------------------------
Fix Version/s: 1.0.0.Beta1
Assignee: Emmanuel Hugonnet (was: Jason Greene)
Component/s: Domain Management
(was: Server)
> IO error during deployment scanning triggers undeployment
> ---------------------------------------------------------
>
> Key: WFCORE-210
> URL: https://issues.jboss.org/browse/WFCORE-210
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha10
> Reporter: James Livingston
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications.
> This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs.
> It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months