March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin... ] Carlo de Wolf updated JBMETA-400: --------------------------------- Git Pull Request: https://github.com/jboss/metadata/pull/110 > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8444) Upgrade proton to align with Artemis

by James Netherton (JIRA)

James Netherton created WFLY-8444: ------------------------------------- Summary: Upgrade proton to align with Artemis Key: WFLY-8444 URL: https://issues.jboss.org/browse/WFLY-8444 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: James Netherton Assignee: Jeff Mesnil I'm working on integrating the Apache Camel AMQP component with WildFly: https://github.com/wildfly-extras/wildfly-camel/issues/1405 I'd like to make use of WildFly's existing {{org.apache.qpid.proton}} module. However, the Proton libraries are quite old. I see that the Artemis version referenced on the WildFly master branch is 1.5.3. Can we align the Proton version used in WildFly with the one used by Artemis 1.5.3 (0.16.0)? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMETA-400) javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/JBMETA-400?page=com.atlassian.jira.plugin... ] Carlo de Wolf reassigned JBMETA-400: ------------------------------------ Assignee: Carlo de Wolf > javax.xml.bind.DatatypeConverter is deprecated in Java 9 and should not be used > ------------------------------------------------------------------------------- > > Key: JBMETA-400 > URL: https://issues.jboss.org/browse/JBMETA-400 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 10.0.0.Final > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Well, then the trace you provided doesn't include everything. You can also configure the leak detector agent to dump only non-closed descriptors, this way it is easier to find culprit. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2534) SlaveReconnectTestCase fails with security manager in WF core

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2534?page=com.atlassian.jira.plugi... ] Martin Simka reassigned WFCORE-2534: ------------------------------------ Assignee: Martin Simka > SlaveReconnectTestCase fails with security manager in WF core > ------------------------------------------------------------- > > Key: WFCORE-2534 > URL: https://issues.jboss.org/browse/WFCORE-2534 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Jan Tymel > Assignee: Martin Simka > > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test01_OrderedExtensionsAndDeployments* > *org.jboss.as.test.integration.domain.slavereconnect.SlaveReconnectTestCase#test02_DeploymentOverlays* > {{cd testsuite/domain/}} > {{mvn test -Dtest=SlaveReconnectTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > [Server:server-affected] 13:16:12,425 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service test.deployment.one: org.jboss.msc.service.StartException in service test.deployment.one: Failed to start service > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0] > [Server:server-affected] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0] > [Server:server-affected] at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0] > [Server:server-affected] Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "test.deployment.prop.one" "write")" in code source "(vfs:/content/reconnect-slave-depone.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.reconnect-slave-depone.jar" from Service Module Loader") > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) [wildfly-elytron-1.1.0.Beta27-redhat-1.jar:1.1.0.Beta27-redhat-1] > [Server:server-affected] at java.lang.System.setProperty(System.java:476) [vm.jar:1.8.0] > [Server:server-affected] at org.jboss.as.test.integration.domain.slavereconnect.deployment.ServiceActivatorBaseDeployment.start(ServiceActivatorBaseDeployment.java:64) > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1] > [Server:server-affected] ... 3 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Mahesh Reddy (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Mahesh Reddy commented on WFLY-8160: ------------------------------------ Regarding the lots of open sockets, For all these open sockets, there are equal number of close sockets. So this is not related to the open pipe leak. If i give the java processId to lsof -p <pid> and again check after webservice response, i see one open pipe gets added after webservice response. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2165) TP.receive() should also handle InputStreams

by Bela Ban (JIRA)

Bela Ban created JGRP-2165: ------------------------------ Summary: TP.receive() should also handle InputStreams Key: JGRP-2165 URL: https://issues.jboss.org/browse/JGRP-2165 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.2 Currently, {{TP.receive()}} is passed a byte[] buffer as parameter. This is OK for UDP and TCP_NIO2, however, in TCP we're dealing with a socket input stream. TcpConnection reads the length, then copies {{length}} bytes into a byte[] buffer and finally calls TP.receive() with the byte[] buffer as argument. The byte[] buffer and the copying of read data into it is superfluous if TP.receive() could also accept input streams as argument. Therefore introduce an additional {{TP.receive(InputStream in, int offset, int length}}, which reads directly from the socket's input stream and gets rid of the intermediate byte buffer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Looking at the output of the file leak detector, there are no leaks in any of WildFly related code. However, you do have somewhat a problem with **LOTS** of open sockets that are opened by zeromq. This is the trace that repeates pretty much through the whole file: {noformat} 2017-03-23 17:30:38,412 ERROR [AbstractLoggingWriter] (iothread-2) Opened socket channel by thread:iothread-2 on Thu Mar 23 17:30:38 PDT 2017 at sun.nio.ch.SocketChannelImpl.<init>(SocketChannelImpl.java:108) at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:60) at java.nio.channels.SocketChannel.open(SocketChannel.java:145) at zmq.TcpConnecter.open(TcpConnecter.java:292) at zmq.TcpConnecter.startConnecting(TcpConnecter.java:215) at zmq.TcpConnecter.timerEvent(TcpConnecter.java:206) at zmq.IOObject.timerEvent(IOObject.java:129) at zmq.PollerBase.executeTimers(PollerBase.java:131) at zmq.Poller.run(Poller.java:187) at java.lang.Thread.run(Thread.java:745) {noformat} In linux open socket channel also consumes file descriptor and this is most probably your root cause of the issue. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8443) Elytron, specify cipher-suite-filter default

by Martin Choma (JIRA)

Martin Choma created WFLY-8443: ---------------------------------- Summary: Elytron, specify cipher-suite-filter default Key: WFLY-8443 URL: https://issues.jboss.org/browse/WFLY-8443 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker Elytron comes with default use-cipher-suites-order = true. {code} "use-cipher-suites-order" => { "type" => BOOLEAN, "description" => "To honor local cipher suites preference.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => true, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } {code} It means honor server cipher suites preference. Because of that Elytron has to provide also some carefully selected cipher-suite-filter default {code} "cipher-suite-filter" => { "type" => STRING, "description" => "The filter to apply to specify the enabled cipher suites.", "expressions-allowed" => true, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } {code} Nowadays default is just {{org.wildfly.security.ssl.CipherSuiteSelector#openSslDefault()}} ("DEFAULT") -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8442) resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor

by Jim Ma (JIRA)

Jim Ma created WFLY-8442: ---------------------------- Summary: resteasy.scan in context parameter doesn't need to be handled in JaxrsIntegrationProcessor Key: WFLY-8442 URL: https://issues.jboss.org/browse/WFLY-8442 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.1.0.Final Reporter: Jim Ma Assignee: Jim Ma Fix For: 11.0.0.Alpha1 resteasy.scan , resteasy.scan.provider and resteasy.scan.resources are already processed in JaxrsScanningProcessor. There is no effect to handle it in JaxrsIntegrationProcessor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017