[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
[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
[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
[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
[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
[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
[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