October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice causes JVM crash

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-5432?page=com.atlassian.jira.plugin.... ] Alessio Soldano closed WFLY-5432. --------------------------------- Resolution: Cannot Reproduce Bug > Wildfly SOAP webservice causes JVM crash > ---------------------------------------- > > Key: WFLY-5432 > URL: https://issues.jboss.org/browse/WFLY-5432 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.1.Final, 10.0.0.CR2 > Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2 > Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final > Reporter: Davide Marchetti > Assignee: Alessio Soldano > Priority: Blocker > Labels: crash, jvm, soap, webservice > Attachments: SOAPTest.war > > > The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test. > The error printed is: > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352 > # > # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00) > # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops) > # Problematic frame: > # J org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object; > # > # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > > # > # If you would like to submit a bug report, please include > # instructions on how to reproduce the bug and visit: > # 15:56:03,314 INFO [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ... > http://icedtea.classpath.org/bugzilla > # > The webservice does nothing, just a System.out.print("xxxxx"). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-309) Release WildFly Elytron 1.0.1.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-309: ------------------------------------ Summary: Release WildFly Elytron 1.0.1.Final Key: ELY-309 URL: https://issues.jboss.org/browse/ELY-309 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.1.CR1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5456) Failback of standalone JMS client fails with http connector

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-5456?page=com.atlassian.jira.plugin.... ] Miroslav Novak moved JBEAP-1213 to WFLY-5456: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5456 (was: JBEAP-1213) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: JMS (was: JMS) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR2 (was: 7.0.0.DR11 (Alpha)) > Failback of standalone JMS client fails with http connector > ----------------------------------------------------------- > > Key: WFLY-5456 > URL: https://issues.jboss.org/browse/WFLY-5456 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR2 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Critical > Attachments: log.txt, servers.zip > > > Failback of standalone JMS client fails if http connector is used. There are 2 EAP 7.0.0.DR11 (Artemis 1.1.0) servers configured in dedicated topology with shared store. > If live server is killed (clients failover) and then restarted (so failback occurs) then sometimes client does not failback to live server. > From the thread dump of one client it seems that it's stuck on: > {code} > Stack trace of thread: Thread[Thread-16,5,main] > Stack trace of thread: Thread[Thread-2 (ActiveMQ-client-global-threads-1995983824),5,ActiveMQ-client-global-threads-1995983824] > ---sun.misc.Unsafe.park(Native Method) > ---java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > ---java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > ---java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > ---java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > ---org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:130) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:770) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:694) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:558) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:461) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$400(ClientSessionFactoryImpl.java:68) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1120) > ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:57) > ---org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:204) > ---org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:179) > ---org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946) > ---org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94) > ---java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > ---java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ---java.lang.Thread.run(Thread.java:745) > {code} > See attached log.txt for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-308) Backport OpenSSL Style Cipher Selection 'ALL'

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-308: ------------------------------------ Summary: Backport OpenSSL Style Cipher Selection 'ALL' Key: ELY-308 URL: https://issues.jboss.org/browse/ELY-308 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.1.CR1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3330) Support enabled-cipher-suites="ALL"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3330?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3330: ---------------------------------------- Just converted to be an independent task as technically this is not a part of the last round of SSL changes. > Support enabled-cipher-suites="ALL" > ------------------------------------ > > Key: WFLY-3330 > URL: https://issues.jboss.org/browse/WFLY-3330 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Affects Versions: 8.1.0.CR1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 10.0.0.Final > > > If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers. > Using the "ALL" keyword with a list of excluded elements this becomes easy to configure. > The expected fopattern would be ALL:!ELT1:!ELT2 > Thus ALL:!MD5 would enable all supported ciphers except MD5. > This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3330) Support enabled-cipher-suites="ALL"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3330?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3330: ----------------------------------- Parent: (was: WFLY-3224) Issue Type: Task (was: Sub-task) > Support enabled-cipher-suites="ALL" > ------------------------------------ > > Key: WFLY-3330 > URL: https://issues.jboss.org/browse/WFLY-3330 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Affects Versions: 8.1.0.CR1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 10.0.0.Final > > > If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers. > Using the "ALL" keyword with a list of excluded elements this becomes easy to configure. > The expected fopattern would be ALL:!ELT1:!ELT2 > Thus ALL:!MD5 would enable all supported ciphers except MD5. > This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1030) PS1 scripts for standalone and domain do not survive :shutdown(restart=true)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1030?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-1030: -------------------------------- Fix Version/s: 2.0.0.CR6 > PS1 scripts for standalone and domain do not survive :shutdown(restart=true) > ---------------------------------------------------------------------------- > > Key: WFCORE-1030 > URL: https://issues.jboss.org/browse/WFCORE-1030 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Rostislav Svoboda > Assignee: Tomaz Cerar > Fix For: 2.0.0.CR6 > > > PS1 scripts for standalone and domain do not survive :shutdown(restart=true) > {code} > [standalone@localhost:9990 /] :shutdown(restart=true) > {"outcome" => "success"} > [standalone@localhost:9990 /] ls > Failed to perform operation: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://localhost:9990. > The connection failed: WFLYPRT0053: Could not connect to http-remoting://localhost:9990. > The connection failed: Connection refused: no further information > {code} > Domain the same > {code} > [domain@localhost:9990 /] /host=master:shutdown(restart=true) > ... > {code} > FYI - scripts were taken from https://github.com/ctomc/wildfly-core/commits/powershell -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5455) [Migration operation] [Web to Undertow] migration of access-log prefix attribute doesn't take into account default value resulting in incosistent result.

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5455?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-5455: ----------------------------------- Affects Version/s: 10.0.0.CR2 > [Migration operation] [Web to Undertow] migration of access-log prefix attribute doesn't take into account default value resulting in incosistent result. > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5455 > URL: https://issues.jboss.org/browse/WFLY-5455 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR2 > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Optional > > Access log prefix in web subsystem is by default {{access-log.}}, in Undertow subsystem it is {{access-log}}. Note the difference, there is "." at the end in case of Web. > There is inconsistency of migrate operation when migrating {{prefix}} attribute. When {{prefix}} is not explicitly defined in Web (=> default is used => {{access-log.}}, note the dot at the end. It is migrated to default Undertow prefix, which is {{access-log}} (missing "." at the end). > In case of having explicitely set {{prefix="access-log."}}, it is the same value as the default value in Web and in this case this is migrated to {{access-log.}} (the "." is there). > => two equivalent Web subsystem configuration of access-log result in two different configurations in Undertow, which is not expected behaviour. > As this impacts only access-log naming, I am considering this only as minor issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1032) Upgrade to WildFly Elytron 1.0.1.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1032: ---------------------------------------- Summary: Upgrade to WildFly Elytron 1.0.1.Final Key: WFCORE-1032 URL: https://issues.jboss.org/browse/WFCORE-1032 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 2.0.0.CR6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5455) [Migration operation] [Web to Undertow] migration of access-log prefix attribute doesn't take into account default value resulting in incosistent result.

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-5455: -------------------------------------- Summary: [Migration operation] [Web to Undertow] migration of access-log prefix attribute doesn't take into account default value resulting in incosistent result. Key: WFLY-5455 URL: https://issues.jboss.org/browse/WFLY-5455 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Radim Hatlapatka Assignee: Stuart Douglas Priority: Optional Access log prefix in web subsystem is by default {{access-log.}}, in Undertow subsystem it is {{access-log}}. Note the difference, there is "." at the end in case of Web. There is inconsistency of migrate operation when migrating {{prefix}} attribute. When {{prefix}} is not explicitly defined in Web (=> default is used => {{access-log.}}, note the dot at the end. It is migrated to default Undertow prefix, which is {{access-log}} (missing "." at the end). In case of having explicitely set {{prefix="access-log."}}, it is the same value as the default value in Web and in this case this is migrated to {{access-log.}} (the "." is there). => two equivalent Web subsystem configuration of access-log result in two different configurations in Undertow, which is not expected behaviour. As this impacts only access-log naming, I am considering this only as minor issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2015