[JBoss JIRA] (WFLY-5554) JMS Bridge parameters are optional in schema, runtime makes them required
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5554?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5554:
------------------------------
Fix Version/s: 10.0.0.Final
> JMS Bridge parameters are optional in schema, runtime makes them required
> -------------------------------------------------------------------------
>
> Key: WFLY-5554
> URL: https://issues.jboss.org/browse/WFLY-5554
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> From AMQ XSD: <xs:attribute name="quality-of-service" use="optional">
> At runtime:
> 09:10:41,213 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Core 2.0.0.CR7 "Kenny" starting
> 09:10:44,070 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("jms-bridge" => "a-to-c-bridge")
> ]) - failure description: "WFLYCTL0155: quality-of-service may not be null"
> 09:10:44,111 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations"
> 09:10:44,114 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations\""
> 09:10:44,118 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5554) JMS Bridge parameters are optional in schema, runtime makes them required
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5554?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-5554:
---------------------------------
Assignee: Jeff Mesnil (was: Jason Greene)
> JMS Bridge parameters are optional in schema, runtime makes them required
> -------------------------------------------------------------------------
>
> Key: WFLY-5554
> URL: https://issues.jboss.org/browse/WFLY-5554
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Bartosz Baranowski
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> From AMQ XSD: <xs:attribute name="quality-of-service" use="optional">
> At runtime:
> 09:10:41,213 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Core 2.0.0.CR7 "Kenny" starting
> 09:10:44,070 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("jms-bridge" => "a-to-c-bridge")
> ]) - failure description: "WFLYCTL0155: quality-of-service may not be null"
> 09:10:44,111 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations"
> 09:10:44,114 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations\""
> 09:10:44,118 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5557) Kerberos authentication for remoting on hostname which contains uppercase letter
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-5557?page=com.atlassian.jira.plugin.... ]
Lin Gao reassigned WFLY-5557:
-----------------------------
Assignee: Lin Gao
> Kerberos authentication for remoting on hostname which contains uppercase letter
> --------------------------------------------------------------------------------
>
> Key: WFLY-5557
> URL: https://issues.jboss.org/browse/WFLY-5557
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Remoting, Security
> Affects Versions: 10.0.0.CR3
> Reporter: Martin Choma
> Assignee: Lin Gao
> Priority: Critical
>
> When EAP runs on server, which contains upper case in hostname (e.g. localhost.Localdomain), it is unpossible to make kerberos authentication in remoting to work properly.
> JDK constructs TGT-REQ with lower case hostname. But remoting client create connection to EAP with upper case letters, what cause problems.
> RFC4120 "The Kerberos Network Authentication Service" [1] in chapter "6.2.1. Name of Server Principals" requires ??Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host MUST be lowercase.??
> Based on information from RFC, IMHO, EAP should handle such scenario. Either remoting client should send lowercase hostname or security realm should map principal case insensitively and look for lower-case keytab record, e.g. remote/localhost.localdomain.
> [1] https://www.ietf.org/rfc/rfc4120.txt
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5608) Unable to configure https using CLI with attribute enabled-cipher-suites
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5608?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-571 to WFLY-5608:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5608 (was: UNDERTOW-571)
Component/s: Web (Undertow)
(was: Security)
Affects Version/s: (was: 1.3.1.Final)
> Unable to configure https using CLI with attribute enabled-cipher-suites
> ------------------------------------------------------------------------
>
> Key: WFLY-5608
> URL: https://issues.jboss.org/browse/WFLY-5608
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> User is unable to configure https using enabled-cipher-suites attribute
> {code}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}},
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> {code}
> 14:52:20,753 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.NullPointerException
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 14:52:20,753 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
> This works OK. It means reload is used between commands
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> reload
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {code}
> Also same commands without enabled-cipher-suites works OK
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-protocols="TLSv1")
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Stefano Picozzi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Stefano Picozzi updated DROOLS-932:
-----------------------------------
Attachment: Drools-932-TestCase.zip
The test case now works. Two changes were needed:
1) Added following line to all my rule files, otherwise get Exception splat:
dialect "mvel"
2) Added the Header as suggested above to the POST invocation.
To replicate pull down my docker image spicozzi/weightwatcher2 and then run the "post" sh script in attached file. Note that there is no need to create the kie-server Container, as I am leveraging new 6.3 feature which persists the container once created.
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
> Attachments: Drools-932-TestCase.zip, Drools-932-TestCase.zip
>
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1089:
----------------------------------------
Summary: IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload
Key: WFCORE-1089
URL: https://issues.jboss.org/browse/WFCORE-1089
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Test Suite
Affects Versions: 2.0.0.CR9
Reporter: Brian Stansberry
IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made.
I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed.
IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFLY-5607) EJB Server side is needlessly closing remoting channel
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-5607:
----------------------------------
Summary: EJB Server side is needlessly closing remoting channel
Key: WFLY-5607
URL: https://issues.jboss.org/browse/WFLY-5607
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.CR4
Reporter: Brad Maxwell
When an EJB Bean throws a Runtime exception, it is causing the server side to close the remoting channel. This causes several issues such as performance issue of having to recreate the channel, channel leak on the client side and some occasional EJBCLIENT...25 - no ejb receiver exceptions on the client side.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months