August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-109) BBCode support for standalone version

by Ryszard Kozmik (JIRA)

BBCode support for standalone version ------------------------------------- Key: JBFORUMS-109 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109 Project: JBoss Forums Issue Type: Task Components: Forum Enhancements Reporter: Ryszard Kozmik Fix For: 1.0.0 Alpha BBCode parser is now working only in portal environment. We need make it work as a standalone too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 days, 21 hours

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 month, 1 week

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

7 months

3
10
0 / 0

[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-1172: -------------------------------------- Can you try with this patch? https://github.com/wildfly/wildfly/pull/6650 > mechanism to load tag libraries from module > ------------------------------------------- > > Key: WFLY-1172 > URL: https://issues.jboss.org/browse/WFLY-1172 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Ivica Loncar > Assignee: Stuart Douglas > Priority: Critical > Labels: modules, tag, taglib, tld > Fix For: 9.0.0.Beta1 > > Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff > > Original Estimate: 1 day > Remaining Estimate: 1 day > > tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF. > The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way. > Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3777) Upgrade mod_cluster to 1.3.1.Alpha1

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3777?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-3777: -------------------------------------- Change log: https://issues.jboss.org/browse/MODCLUSTER/fixforversion/12324067/?select... > Upgrade mod_cluster to 1.3.1.Alpha1 > ----------------------------------- > > Key: WFLY-3777 > URL: https://issues.jboss.org/browse/WFLY-3777 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > We should get the upgrades going so that we integrate and find bugs quickly. > This will also need to integrate the last piece of WFLY-457. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ] Frank Langelage updated WFLY-1172: ---------------------------------- Attachment: ExternalTld.txt ExternalTldParsingDeploymentProcessor.java.diff The .diff file shows the messages I put in. The .txt file shows the messages from server.log for any web module of my ear. > mechanism to load tag libraries from module > ------------------------------------------- > > Key: WFLY-1172 > URL: https://issues.jboss.org/browse/WFLY-1172 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Ivica Loncar > Assignee: Stuart Douglas > Priority: Critical > Labels: modules, tag, taglib, tld > Fix For: 9.0.0.Beta1 > > Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff > > Original Estimate: 1 day > Remaining Estimate: 1 day > > tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF. > The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way. > Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-1172: --------------------------------------- This implementation created a big performance drop when deploying my ear. Before it took about 1 min 15s to deploy, now the 5 minutes are not enough and deployment gets a timeout and is stopped. My ear is of 22 MB size, contains 23 ejb and web modules. If I revert changes in UndertowSubsystemAdd.java everything is fine again. I added some debug statements to ExternalTldParsingDeploymentProcessor.java and found out, that line 83 is causing the problem. The first call of next for a deploymentunit takes a lot of time, subsequent calls for the same DU are no problem then. Getting the first element takes about 1m - 1m 30s and lot of memory is used, as I see many lines of the garbage collector in this period. > mechanism to load tag libraries from module > ------------------------------------------- > > Key: WFLY-1172 > URL: https://issues.jboss.org/browse/WFLY-1172 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Ivica Loncar > Assignee: Stuart Douglas > Priority: Critical > Labels: modules, tag, taglib, tld > Fix For: 9.0.0.Beta1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF. > The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way. > Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts

by Arcadiy Ivanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ] Arcadiy Ivanov edited comment on WFLY-3703 at 8/31/14 3:23 AM: --------------------------------------------------------------- Can this be pushed into the 8.x branch as well? The pull into wildfly-core was merged (https://github.com/wildfly/wildfly-core/pull/110) was (Author: arcivanov): Can this be pushed into the 8.x branch as well? > arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts > --------------------------------------------------------------------------------------- > > Key: WFLY-3703 > URL: https://issues.jboss.org/browse/WFLY-3703 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.1.0.Final > Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > Reporter: Arcadiy Ivanov > Assignee: Alexey Loubyansky > Priority: Blocker > Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt > > > Trying to use Arquillian with remote multi-host domain. > Now see the code snippet below: > * readRootNode calls readResource with includeRuntime set to true. > * readResource also sets recursive to true. > However due to this behavior of read-resource *no hosts other than domain controller's are visible to Arquillian*: > [proxies – (boolean, default is false) – whether to include remote resources in a recursive query (i.e. host level resources from slave Host Controllers in a query of the Domain Controller; running server resources in a query of a host).|https://docs.jboss.org/author/display/WFLY8/Global+operations] > +As a result if I have a DC on localhost with no servers and Host1 with Node1 on 127.0.0.2 and Host2 with Node2 on 127.0.0.3, Arquillian will not find ANY servers to deploy to - no proxies (remote hosts) will be enumerated.+ > {noformat} > private void readRootNode() throws Exception { > rootNode = readResource(new ModelNode()); > } > private ModelNode readResource(ModelNode address) throws Exception { > return readResource(address, true); > } > private ModelNode readResource(ModelNode address, boolean includeRuntime) throws Exception { > final ModelNode operation = new ModelNode(); > operation.get(OP).set(READ_RESOURCE_OPERATION); > operation.get(RECURSIVE).set("true"); > operation.get(INCLUDE_RUNTIME).set(includeRuntime); > operation.get(OP_ADDR).set(address); > return executeForResult(operation); > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts

by Arcadiy Ivanov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ] Arcadiy Ivanov commented on WFLY-3703: -------------------------------------- Can this be pushed into the 8.x branch as well? > arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts > --------------------------------------------------------------------------------------- > > Key: WFLY-3703 > URL: https://issues.jboss.org/browse/WFLY-3703 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.1.0.Final > Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > Reporter: Arcadiy Ivanov > Assignee: Alexey Loubyansky > Priority: Blocker > Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt > > > Trying to use Arquillian with remote multi-host domain. > Now see the code snippet below: > * readRootNode calls readResource with includeRuntime set to true. > * readResource also sets recursive to true. > However due to this behavior of read-resource *no hosts other than domain controller's are visible to Arquillian*: > [proxies – (boolean, default is false) – whether to include remote resources in a recursive query (i.e. host level resources from slave Host Controllers in a query of the Domain Controller; running server resources in a query of a host).|https://docs.jboss.org/author/display/WFLY8/Global+operations] > +As a result if I have a DC on localhost with no servers and Host1 with Node1 on 127.0.0.2 and Host2 with Node2 on 127.0.0.3, Arquillian will not find ANY servers to deploy to - no proxies (remote hosts) will be enumerated.+ > {noformat} > private void readRootNode() throws Exception { > rootNode = readResource(new ModelNode()); > } > private ModelNode readResource(ModelNode address) throws Exception { > return readResource(address, true); > } > private ModelNode readResource(ModelNode address, boolean includeRuntime) throws Exception { > final ModelNode operation = new ModelNode(); > operation.get(OP).set(READ_RESOURCE_OPERATION); > operation.get(RECURSIVE).set("true"); > operation.get(INCLUDE_RUNTIME).set(includeRuntime); > operation.get(OP_ADDR).set(address); > return executeForResult(operation); > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1794: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 910773|https://bugzilla.redhat.com/show_bug.cgi?id=910773] from NEW to CLOSED > OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages > ------------------------------------------------------------------------------------------- > > Key: JGRP-1794 > URL: https://issues.jboss.org/browse/JGRP-1794 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.2.13 > Environment: Solaris, RHEL, Windows, HPUX > tcp stack only > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions. > The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving > The test does this: > - send 1 regular message from A -> B > - send 9 OOB meesages from A -> B > - wait 20 seconds for messages to arrive > - check that all 9 OOB messages have arrived > - unblock the latch > - check that all 10 message have arrived > The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are: > [3,2,6,8,9,10,4] > [2,3,4,8,9,5] > [2,3,4,8,7,9] > [2,3,5,4,6] > So, it appears that either the messages are slow to arrive or not arriving at all. > A correct result looks like this: > {noformat} > list = [2, 4, 3, 7, 8, 9, 10, 5, 6] > [main]: releasing latch > list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1] > {noformat} > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 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 August 2014