[JBoss JIRA] (WFLY-6551) Incorrect log message in class ClientSessionFactoryImpl
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6551?page=com.atlassian.jira.plugin.... ]
Chen Maoqian reassigned WFLY-6551:
----------------------------------
Assignee: Chen Maoqian (was: Andy Taylor)
> Incorrect log message in class ClientSessionFactoryImpl
> -------------------------------------------------------
>
> Key: WFLY-6551
> URL: https://issues.jboss.org/browse/WFLY-6551
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Priority: Minor
>
> There is incorrect logging message present in method {{establishNewConnection()}} in class {{org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl}} .
>
> {noformat}
> protected RemotingConnection establishNewConnection() {
> ....
> RemotingConnection newConnection = clientProtocolManager.connect(...);
> newConnection.addFailureListener(new DelegatingFailureListener(newConnection.getID()));
> schedulePing();
> if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
> ActiveMQClientLogger.LOGGER.trace("returning " + connection);
> }
> return newConnection;
> }
> {noformat}
> Log message says, that it is returning connection (old one, present as an attribute of class), but connection stored in {{newConnection}} variable is returned (and then it is set as this.connection).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6551) Incorrect log message in class ClientSessionFactoryImpl
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6551?page=com.atlassian.jira.plugin.... ]
Chen Maoqian moved JBEAP-4327 to WFLY-6551:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6551 (was: JBEAP-4327)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: ActiveMQ)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.CR1)
> Incorrect log message in class ClientSessionFactoryImpl
> -------------------------------------------------------
>
> Key: WFLY-6551
> URL: https://issues.jboss.org/browse/WFLY-6551
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Andy Taylor
> Priority: Minor
>
> There is incorrect logging message present in method {{establishNewConnection()}} in class {{org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl}} .
>
> {noformat}
> protected RemotingConnection establishNewConnection() {
> ....
> RemotingConnection newConnection = clientProtocolManager.connect(...);
> newConnection.addFailureListener(new DelegatingFailureListener(newConnection.getID()));
> schedulePing();
> if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
> ActiveMQClientLogger.LOGGER.trace("returning " + connection);
> }
> return newConnection;
> }
> {noformat}
> Log message says, that it is returning connection (old one, present as an attribute of class), but connection stored in {{newConnection}} variable is returned (and then it is set as this.connection).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-4618:
-----------------------------------
[~stuartdouglas] I did some initial research looking at actual SAM implementations for companies I worked for (closed source, but very practical) and open source ones, and almost none really use {{MessagePolicy}}. I found 1 that uses it as an alternative to {{messageInfo.getMap().get("javax.security.auth.message.MessagePolicy.isMandatory"))}}. See https://github.com/arjantijms/cas-jaspic/blob/master/src/main/java/com/go...
Interestingly, I also found an existing discussion regarding early JASPIC support in WildFly, where one participant had the exact same idea about the {{MessagePolicy}}:
{quote}
Spec 3.8.1.1 seems pretty unambigious to me on setting the property.
It is worth noting, that there are actually two different isMandatory flags in play:
The one passed in the MessageInfo arguement to SAM.validateRequest tells if this particular request is accessing a protected resource, while the other is passed to SAM.initialize in the requestPolicy argument, that is analogous to the JAAS auth module required/optional flag.
{quote}
See https://github.com/wildfly/wildfly/pull/5558
So at least it seems a somewhat common confusion. To be continued.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5973) org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
by Nilindra Fernando (JIRA)
[ https://issues.jboss.org/browse/WFLY-5973?page=com.atlassian.jira.plugin.... ]
Nilindra Fernando commented on WFLY-5973:
-----------------------------------------
Have not tested in Wildfly 10 directly. However did checked in WF 9.0.2.Final which bundles jastow-1.1.1.Final.jar and cross checked the applicable fixes available in jastow-2.0.0.Final.jar.
This is from jastow-2.0.0.Final.jar code.
{code}
org.apache.jasper.runtime.PageContextImpl.java
public void release()
......
for (BodyContentImpl body : this.outs) {
body.recycle();
}
......
{code}
In the above code, the below line is missing, hence this small leak still exists.
I guess the fix should be;
{code}
org.apache.jasper.runtime.PageContextImpl.java
public void release()
......
for (BodyContentImpl body : this.outs) {
body.recycle();
}
this.outs = null;
......
{code}
Did few testings around this area and it looks good. Please check and incorporate.
> org.apache.jasper.runtime.BodyContentImpl memory leaking when using JSTL Simple tag what having body is scriptless
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5973
> URL: https://issues.jboss.org/browse/WFLY-5973
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final
> Reporter: Loc Ha
> Assignee: Tomaz Cerar
> Priority: Critical
> Fix For: 10.0.0.CR1
>
>
> -- Create any JSTL Simple tag (SimpleTagSupport) that having body is scriptless
> -- Create a JSP using the Simple tag
> -- Request the JSP multi time
> -- Using visualvm 1.3.8 to monitor the allocations of org.apache.jasper.runtime.BodyContentImpl --> You will see a lot of instance of BodyContentImpl created
> -- Click on Perform GC on VisualVM --> The remainging BodyContentImpl didn't go down to ZERO ---> Leaking memory
> -- Did the same test using Glashfish 4 --> When click on Perform GC --> BodyContentImpl went down to Zero --> No leaking memory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to undefined connector
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5688:
---------------------------------
Summary: mod_cluster subsystem remains silent if connector set to undefined connector (was: mod_cluster subsystem remains silent if connector set to http)
> mod_cluster subsystem remains silent if connector set to undefined connector
> ----------------------------------------------------------------------------
>
> Key: WFLY-5688
> URL: https://issues.jboss.org/browse/WFLY-5688
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG.
> When switched back to {{connector="ajp"}}, there are the well known comforting messages:
> {noformat}
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> {noformat}
> Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1135) NullPointerExceptions when using multiple concurrent KieSessions
by Sjoerd Cranen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugi... ]
Sjoerd Cranen commented on DROOLS-1135:
---------------------------------------
I have been running 5.4.0.Final patched with the change set from this ticket, and so far have not seen this issue occur again. Thank you for the quick resolution!
> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
> Key: DROOLS-1135
> URL: https://issues.jboss.org/browse/DROOLS-1135
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
> while (true) {
> work = getItemsFromQueue();
> addAndRemoveFacts(kieSession, work);
> kieSession.fireAllRules();
> }
> } finally {
> kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$104/975722152.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$162/1410998625.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$99/1591140286.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1501) Failure to create timestamped config file history fails boot
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1501:
----------------------------------------
Summary: Failure to create timestamped config file history fails boot
Key: WFCORE-1501
URL: https://issues.jboss.org/browse/WFCORE-1501
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.1.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.2.0.Beta1, 3.0.0.Alpha1
Something like the following shouldn't be allowed to fail a boot; if it happens an ERROR should be logged but no exception thrown:
{code}
2016-04-22 22:10:21,247 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.IllegalStateException: WFLYCTL0056: Could not rename C:\BuildAgent\work\38e1ea00f932992d\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\current to C:\BuildAgent\work\38e1ea00f932992d\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\20160422-221021244
at org.jboss.as.controller.persistence.ConfigurationFile.createHistoryDirectory(ConfigurationFile.java:668)
at org.jboss.as.controller.persistence.ConfigurationFile.successfulBoot(ConfigurationFile.java:500)
at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.successfulBoot(BackupXmlConfigurationPersister.java:94)
at org.jboss.as.controller.AbstractControllerService.finishBoot(AbstractControllerService.java:452)
at org.jboss.as.server.ServerService.boot(ServerService.java:367)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
at java.lang.Thread.run(Thread.java:745)
{code}
That stack trace indicates file standalone\configuration\standalone_xml_history\20160422-221021144 must already exist but the 2nd attempt renameTo standalone\configuration\standalone_xml_history\20160422-221021244 has failed. It would be good to sort out what happened, but regardless it should not fail boot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-4618:
-----------------------------------
Thanks to you too Ladislav for confirming that it solves the problem.
As mentioned, I'll do some research for {{MessagePolicy}}.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2056:
---------------------------
Attachment: bla.java
The attached program shows max latencies are mainly dominated by GC. Ue -Xloggc:/tmp/dump.txt to see when there's a collection and the max value will be bigger than that collection. Investigate increasing the new (still called eden in 8?) space.
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: bla.java
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years