[JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to 100% and does not respond
by Giovanni Lovato (JIRA)
[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ]
Giovanni Lovato commented on WFLY-7275:
---------------------------------------
I'm experiencing this too, can you please link your PR? Thank you!
> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
> Key: WFLY-7275
> URL: https://issues.jboss.org/browse/WFLY-7275
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
> Reporter: Krisztian Kocsis
> Assignee: Stuart Douglas
> Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Bartosz Andrzejewski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Bartosz Andrzejewski commented on WFLY-5213:
--------------------------------------------
It worked for MDB, thank you.
But problem with JMSContext remain. There is still comp/TransactionSynchronizationRegistry naming exception - on first conext usage(when creating a message or a producer).
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1877) Content completion does not work for deployment-info --headers
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFCORE-1877:
------------------------------------------
Summary: Content completion does not work for deployment-info --headers
Key: WFCORE-1877
URL: https://issues.jboss.org/browse/WFCORE-1877
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Bartosz Baranowski
Priority: Minor
[standalone@localhost:9990 /] deployment-info --headers
[standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
this does not kick in, should be:
[standalone@localhost:9990 /] deployment-info --headers={
after first <TAB>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1876) Content completion does not work for deployment-info --headers
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1876?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1876:
---------------------------------------
Description:
[standalone@localhost:9990 /] deployment-info --headers
[standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
this does not kick in, should be:
[standalone@localhost:9990 /] deployment-info --headers={
after first <TAB>
> Content completion does not work for deployment-info --headers
> --------------------------------------------------------------
>
> Key: WFCORE-1876
> URL: https://issues.jboss.org/browse/WFCORE-1876
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Priority: Minor
>
> [standalone@localhost:9990 /] deployment-info --headers
> [standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
> this does not kick in, should be:
> [standalone@localhost:9990 /] deployment-info --headers={
> after first <TAB>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7342:
-----------------------------------
Assignee: Ilia Vassilev
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files truncation
by Leonardo Penczek (JIRA)
Leonardo Penczek created WFLY-7345:
--------------------------------------
Summary: Fix big jboss-beans.xml files truncation
Key: WFLY-7345
URL: https://issues.jboss.org/browse/WFLY-7345
Project: WildFly
Issue Type: Bug
Components: POJO
Affects Versions: 10.1.0.Final
Reporter: Leonardo Penczek
Assignee: Ales Justin
If the jboss-beans.xml file is big enough, the value of a property.may be truncated,
Fix for this problem:
In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code:
inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true));
It prevents the truncation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-7338:
------------------------------
Component/s: Logging
> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-7338
> URL: https://issues.jboss.org/browse/WFLY-7338
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Reporter: Patrick Kleindienst
> Assignee: James Perkins
> Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:596)
> at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> at java.io.PrintStream.write(PrintStream.java:482)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> at java.io.PrintStream.write(PrintStream.java:480)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> at java.io.PrintStream.newLine(PrintStream.java:546)
> at java.io.PrintStream.println(PrintStream.java:696)
> at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>
> When disabling SSL both on WildFly and Logstash side, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-7338 to WFCORE-1875:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1875 (was: WFLY-7338)
Component/s: Logging
(was: Logging)
Affects Version/s: (was: 10.0.0.Final)
(was: 10.1.0.Final)
> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1875
> URL: https://issues.jboss.org/browse/WFCORE-1875
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Patrick Kleindienst
> Assignee: James Perkins
> Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:596)
> at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> at java.io.PrintStream.write(PrintStream.java:482)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> at java.io.PrintStream.write(PrintStream.java:480)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> at java.io.PrintStream.newLine(PrintStream.java:546)
> at java.io.PrintStream.println(PrintStream.java:696)
> at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>
> When disabling SSL both on WildFly and Logstash side, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months