[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6123:
---------------------------------
Summary: Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode (was: Infinispan subsystem XSD doesn't document all possible values of <transaction mode="...">)
> Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6123
> URL: https://issues.jboss.org/browse/WFLY-6123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Radoslav Husar
>
> The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}:
> bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA.
> However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values:
> - {{NONE}}
> - {{BATCH}}
> - {{NON_XA}}
> - {{NON_DURABLE_XA}}
> - {{FULL_XA}}
> I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6123:
---------------------------------
Priority: Trivial (was: Major)
> Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6123
> URL: https://issues.jboss.org/browse/WFLY-6123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Radoslav Husar
> Priority: Trivial
>
> The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}:
> bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA.
> However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values:
> - {{NONE}}
> - {{BATCH}}
> - {{NON_XA}}
> - {{NON_DURABLE_XA}}
> - {{FULL_XA}}
> I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6123:
--------------------------------------
The important is the type, which is used for validation, which contains all values alright, see schema/jboss-as-infinispan_4_0.xsd:880
> Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6123
> URL: https://issues.jboss.org/browse/WFLY-6123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Radoslav Husar
> Priority: Trivial
>
> The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}:
> bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA.
> However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values:
> - {{NONE}}
> - {{BATCH}}
> - {{NON_XA}}
> - {{NON_DURABLE_XA}}
> - {{FULL_XA}}
> I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6417) ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6417?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-6417:
----------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6417
> URL: https://issues.jboss.org/browse/WFLY-6417
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Richard Achmatowicz
>
> I have tests that start 2 clusters and a standalone EJB client and do remote EJB invocations like this: standalone EJB client -> cluster 1 (forwarder) -> cluster 2 (target) -> back to cluster 1 -> back to standalone client.
> During a graceful shutdown variant of such tests, where the nodes of the clusters are repeatedly shut down and then brough back up to life, one node at a time, I've seen an {{ArrayIndexOutOfBoundsException}} in EJB client on one of the forwarder nodes:
> {code}
> 2016-03-21 14:26:59,050 ERROR [org.jboss.as.ejb3.invocation] (default task-110) WFLYEJB0034: EJB Invocation failed on component ForwardingBeanImpl for method public abstract java.lang.String org.jboss.qa.eap.clustering.[redacted].testApps.june2013.Bean.test(java.lang.String,long): javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException: 5
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy63.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].testApps.june2013.ForwardingBeanImpl.test(ForwardingBeanImpl.java:30)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 44 more
> {code}
> In the log, this exception is preceded by warnings about failed invocations and "No EJBReceiver available" which I don't understand -- at the time, all nodes should be up and running and seeing each other (which seems to be confirmed by the logs).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6418) IIOP subsystem intermittently does not start if SSL is used
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6418?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-6418:
-----------------------------------
Description:
As part of TCK testing I can see intermittent failure where IIOP subsystem does not start (which causes whole server fails to start) with message of not found a JSEE security domain.
That means if IIOP subsytem is configured to run with ssl it causes whole server failing to start.
{code}
\u001b[0m\u001b[31m09:03:12,609 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:142) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_71] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_71] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_71]Caused by: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:558) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:576) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:485) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543) [rt.jar:1.8.0_71] at org.omg.CORBA.ORB.init(ORB.java:353) [rt.jar:1.8.0_71] at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126) ... 5 moreCaused by: java.lang.RuntimeException: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain at org.wildfly.iiop.openjdk.security.SocketFactory.setORB(SocketFactory.java:92) at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.initializeTransport(ORBConfiguratorImpl.java:271) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:149) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:483) [rt.jar:1.8.0_71] ... 8 moreCaused by: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain ... 12 more
...
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
\u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
\u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
{code}
was:
As part of TCK testing I can see intermittent failure where IIOP subsystem does not start (which causes whole server fails to start) with message of not found a JSEE security domain.
That means if IIOP subsytem is configured to run with ssl it causes whole server failing to start.
{code}
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
\u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
\u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
...
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
\u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
\u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
{code}
> IIOP subsystem intermittently does not start if SSL is used
> ------------------------------------------------------------
>
> Key: WFLY-6418
> URL: https://issues.jboss.org/browse/WFLY-6418
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> As part of TCK testing I can see intermittent failure where IIOP subsystem does not start (which causes whole server fails to start) with message of not found a JSEE security domain.
> That means if IIOP subsytem is configured to run with ssl it causes whole server failing to start.
> {code}
> \u001b[0m\u001b[31m09:03:12,609 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:142) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final-redhat-1.jar:1.2.6.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_71] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_71] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_71]Caused by: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:558) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:576) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:485) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543) [rt.jar:1.8.0_71] at org.omg.CORBA.ORB.init(ORB.java:353) [rt.jar:1.8.0_71] at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126) ... 5 moreCaused by: java.lang.RuntimeException: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain at org.wildfly.iiop.openjdk.security.SocketFactory.setORB(SocketFactory.java:92) at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.initializeTransport(ORBConfiguratorImpl.java:271) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:149) [rt.jar:1.8.0_71] at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:483) [rt.jar:1.8.0_71] ... 8 moreCaused by: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain ... 12 more
> ...
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
> service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
> service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
> WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
> \u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> \u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6418) IIOP subsystem intermittently does not start if SSL is used
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-6418:
--------------------------------------
Summary: IIOP subsystem intermittently does not start if SSL is used
Key: WFLY-6418
URL: https://issues.jboss.org/browse/WFLY-6418
Project: WildFly
Issue Type: Bug
Components: IIOP
Reporter: Ondřej Chaloupka
Assignee: Tomasz Adamski
Priority: Blocker
As part of TCK testing I can see intermittent failure where IIOP subsystem does not start (which causes whole server fails to start) with message of not found a JSEE security domain.
That means if IIOP subsytem is configured to run with ssl it causes whole server failing to start.
{code}
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
\u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
\u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
...
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.iiop-openjdk.orb-service (missing) dependents: [service jboss.iiop-openjdk.naming-service, service jboss.iiop-openjdk.poa-service.rootpoa]
service jboss.iiop-openjdk.poa-service.namingpoa (missing) dependents: [service jboss.iiop-openjdk.naming-service]
service jboss.iiop-openjdk.poa-service.rootpoa (missing) dependents: [service jboss.iiop-openjdk.poa-service.irpoa, service jboss.iiop-openjdk.poa-service.namingpoa, service jboss.iiop-openjdk.naming-service]
WFLYCTL0186: Services which failed to start: service jboss.iiop-openjdk.orb-service
\u001b[0m\u001b[0m09:03:15,758 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
\u001b[0m\u001b[0m09:03:15,770 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.0.Final-redhat-1) stopped in 787ms
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg reopened WFLY-6413:
----------------------------------
This still seems to not be working correctly. Please see my comments here: https://developer.jboss.org/message/953484#953484
Also note that there has been a correction in the Step to Reproduce. The previous `curl` test inadvertently issues a HEAD request. The intent was to issue a GET. The statement has been corrected to:
{noformat}
$ curl -sD - -o /dev/null --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
This is not a problem, necessarily with enabling the range headers, it really seems to be an problem with how the requests are handled and what headers are returned.
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Steps to Reproduce:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will not* play video
* Firefox - *will* play video
Run this from the CLI, not the results:
{noformat}
curl -sD - -o /dev/null --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
was:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will not* play video
* Firefox - *will* play video
Run this from the CLI, not the results:
{noformat}
$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg updated WFLY-6413:
---------------------------------
Steps to Reproduce:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will not* play video
* Firefox - *will* play video
Run this from the CLI, note the results:
{noformat}
curl -sD - -o /dev/null --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
was:
Enable range header as described here:
https://developer.jboss.org/message/953058#953058
Deploy a simple application to WildFly that serves video content via HTML5, like this: https://github.com/slowtrailrunner/html5-vidtest
Load the page with the video (if using the above example then http://localhost:8880/vidtest/) in various browsers:
* Chrome - *will not* play video
* Safari - *will not* play video
* Firefox - *will* play video
Run this from the CLI, not the results:
{noformat}
curl -sD - -o /dev/null --range 0- http://localhost:8880/vidtest/vidtest.mp4
{noformat}
Now deploy the same war to Tomcat 8 and do the above steps again. Notice that the video is playable in all the browsers. Also note the difference in the result from the `curl` test.
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Critical
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month