[JBoss JIRA] (LOGMGR-117) Fork Log4J ConosleAppender to simply handling of calls to System.out
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-117?page=com.atlassian.jira.plugin... ]
Lin Gao reassigned LOGMGR-117:
------------------------------
Assignee: Lin Gao (was: James Perkins)
> Fork Log4J ConosleAppender to simply handling of calls to System.out
> --------------------------------------------------------------------
>
> Key: LOGMGR-117
> URL: https://issues.jboss.org/browse/LOGMGR-117
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Kyle Lape
> Assignee: Lin Gao
>
> While the use of {{ConsoleAppender}} in Log4J application logging configurations is discouraged, JBoss could probably do a better job of managing its use.
> Currently it's possible to encounter a deadlock if thread A invokes {{System.out.println()}} and thread B invokes {{Logger.info()}}. Thread A will get the lock on {{System.out}} (a {{java.io.PrintWriter}}), but then thread B will get the lock on the {{org.apache.log4j.ConsoleAppender}}. Then each thread is waiting on the other's lock.
> The suggested improvement (discussed with [~jamezp]) is to fork Log4J's {{ConsoleAppender}} so that instead of calling {{System.out.println}}, it calls the real {{stdout}}.
> *Bonus enhancement*: Drop a {{WARN}} message to the system root logger discouraging the use of {{ConsoleAppender}} in application configurations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (DROOLS-740) NoSuchMethodError at runtime while evaluating String and Long
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-740?page=com.atlassian.jira.plugin... ]
Toshiya Kobayashi commented on DROOLS-740:
------------------------------------------
Toshiya>
Out of curiosity, why did you remove 20-times-loop from the test case? Is there any trick to force JIT compilation immediately?
Mario>
The trick I use to test and fix JIT compilation issues is setting this flag to true: https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav...
This forces immediate JITting of constraints. When I fix a jit-related bug (and from time to time) I then ran the whole test suite with that flag set to true to check that jit compilation is working with all known use cases.
> NoSuchMethodError at runtime while evaluating String and Long
> -------------------------------------------------------------
>
> Key: DROOLS-740
> URL: https://issues.jboss.org/browse/DROOLS-740
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Fix For: 6.3.0.Beta1
>
>
> When you write a LHS like this,
> {noformat}
> Person( name == "Elizabeth" + new Long(2L) )
> {noformat}
> you will face NoSuchMethodError after 20 times evaluation.
> {noformat}
> testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR!
> java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder;
> at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450)
> at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4437) NPE for all requests on Linux host
by Nicklas Karlsson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4437?page=com.atlassian.jira.plugin.... ]
Nicklas Karlsson commented on WFLY-4437:
----------------------------------------
The host probably runs in a VM but so does other hosts I've seen running WF. The instance is running with the same user privileges as owns the home directory so file permissions shouldn't be a problem. I don't know about SELinux etc but if that would be a problem one would think it would manifest itself more widely. Strange issue.
> NPE for all requests on Linux host
> ----------------------------------
>
> Key: WFLY-4437
> URL: https://issues.jboss.org/browse/WFLY-4437
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Nicklas Karlsson
> Assignee: Stuart Douglas
>
> I have a WF9 upstream master from a few week back running in standalone mode on a CentOS 5.2 Final with a 64bit 1.8.0_25b17 JDK.
> However, every request returns a 500 because of the NPE below. The startup/deployment is normal with no errors in the log
> {code}
> 2015-03-03 10:56:39,790 ERROR [io.undertow.request] (default I/O-1) Undertow request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:57)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:53)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:189)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:113)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:143)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:90)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:49)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {code}
> A WF 8.1.0 runs fine on the host and the same WF9 have run on other Linux hosts but I'm unable to pin down what affects Undertow in this way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4437) NPE for all requests on Linux host
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4437?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-403 to WFLY-4437:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-4437 (was: UNDERTOW-403)
Affects Version/s: (was: 1.2.0.Beta8)
Component/s: Web (Undertow)
(was: Servlet)
> NPE for all requests on Linux host
> ----------------------------------
>
> Key: WFLY-4437
> URL: https://issues.jboss.org/browse/WFLY-4437
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Nicklas Karlsson
> Assignee: Stuart Douglas
>
> I have a WF9 upstream master from a few week back running in standalone mode on a CentOS 5.2 Final with a 64bit 1.8.0_25b17 JDK.
> However, every request returns a 500 because of the NPE below. The startup/deployment is normal with no errors in the log
> {code}
> 2015-03-03 10:56:39,790 ERROR [io.undertow.request] (default I/O-1) Undertow request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:57)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:53)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:189)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:113)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:143)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:90)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:49)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {code}
> A WF 8.1.0 runs fine on the host and the same WF9 have run on other Linux hosts but I'm unable to pin down what affects Undertow in this way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (JBJCA-1254) Tracer improvements
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1254?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1254:
-----------------------------------
Description:
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
* MANAGED_CONNECTION_POOL_CREATE
* MANAGED_CONNECTION_POOL_DESTROY
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
was:
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
> Tracer improvements
> -------------------
>
> Key: JBJCA-1254
> URL: https://issues.jboss.org/browse/JBJCA-1254
> Project: IronJacamar
> Issue Type: Task
> Components: Core
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Fix For: 1.2.3.Final
>
>
> Add the following events:
> * CREATE_CONNECTION_LISTENER_GET
> * CREATE_CONNECTION_LISTENER_PREFILL
> * CREATE_CONNECTION_LISTENER_INCREMENTER
> * DESTROY_CONNECTION_LISTENER_RETURN
> * DESTROY_CONNECTION_LISTENER_IDLE
> * DESTROY_CONNECTION_LISTENER_INVALID
> * DESTROY_CONNECTION_LISTENER_FLUSH
> * DESTROY_CONNECTION_LISTENER_ERROR
> * MANAGED_CONNECTION_POOL_CREATE
> * MANAGED_CONNECTION_POOL_DESTROY
> Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (JBJCA-1254) Tracer improvements
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1254:
--------------------------------------
Summary: Tracer improvements
Key: JBJCA-1254
URL: https://issues.jboss.org/browse/JBJCA-1254
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.3.Final
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-263:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1202610
> Cancelling management op on slave HC tree is broken
> ---------------------------------------------------
>
> Key: WFCORE-263
> URL: https://issues.jboss.org/browse/WFCORE-263
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Attachments: unundeployable.zip
>
>
> If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via:
> /host=master/core-service=management/service=management-operations:find-non-progressing-operation
> /host=slave/core-service=management/service=management-operations:find-non-progressing-operation
> Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again.
> If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive.
> Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled.
> Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (JBASMP-53) Support --runtime-name for deployment on server groups
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-53:
-------------------------------------
Also I'm not sure where I got this idea from because I can't find the where I'd set it with the deployment plan API :)
> Support --runtime-name for deployment on server groups
> ------------------------------------------------------
>
> Key: JBASMP-53
> URL: https://issues.jboss.org/browse/JBASMP-53
> Project: JBoss AS Maven Plugins
> Issue Type: Enhancement
> Components: wildfly
> Reporter: James Perkins
> Assignee: James Perkins
>
> The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).
> It would be nice if the JBoss Maven plugin could add another configuration parameter for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months