[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-3703:
------------------------------------
Summary: :read-resource(recursive=true) ignoring non-DC hosts
Key: WFLY-3703
URL: https://issues.jboss.org/browse/WFLY-3703
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
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
This issues comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
contains output among others:
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
contains only
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Skip Skip (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Skip Skip commented on DROOLS-553:
----------------------------------
I just wasted major league time on this. And while it may be all "maven's fault" it still does not leave one with a warm fuzzy experience with your software.
Maybe it would be helpful to put something like: "!!! WARNING DON'T USE MAVEN 3.2.2 !!!"
just an idea
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFCORE-41) Update slf4j-api to 1.7.5
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-41?page=com.atlassian.jira.plugin.... ]
James Perkins moved WFLY-2437 to WFCORE-41:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-41 (was: WFLY-2437)
Affects Version/s: (was: 8.0.0.Beta1)
Component/s: Logging
(was: Logging)
> Update slf4j-api to 1.7.5
> -------------------------
>
> Key: WFCORE-41
> URL: https://issues.jboss.org/browse/WFCORE-41
> Project: WildFly Core
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Jorge Solorzano
> Assignee: James Perkins
> Labels: slf4j
>
> The logger factories in most SLF4J modules namely in jcl-over-slf4j, log4j-over-slf4j, slf4j-jcl, slf4j-jdk14, slf4j-log4j12, and slf4j-simple now use a ConcurrentHashMap instead of a regular HashMap to cache logger instances. This change significantly improves logger retrieval times at the cost of some memory overhead.
> Acording to SLF4J developers:
> Given the significance of these performance improvements, users are highly encouraged to migrate to SLF4J version 1.7.5 or later.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3700) Optional Module for Camel
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3700?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3700:
-----------------------------------
How is this WildFly related? this should be provided by project(s) that deal with camel.
Also it could be community driven effort, as part of wildfly-extras initiative.
> Optional Module for Camel
> -------------------------
>
> Key: WFLY-3700
> URL: https://issues.jboss.org/browse/WFLY-3700
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Environment: Any
> Reporter: Jeremy Davis
> Labels: modules
> Fix For: Awaiting Volunteers
>
>
> It would be nice to have an optional module with the necessary jars to run Camel
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
James Perkins moved WFLY-3620 to WFCORE-40:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-40 (was: WFLY-3620)
Affects Version/s: (was: 8.1.0.Final)
Component/s: Logging
(was: Logging)
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3620) Deadlock while logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3620?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-3620:
-------------------------------------
This is a tough question. It seems to be stuck on the {{Throwable.fillInStackTrace()}} in a native method. I'm not sure if the native method has a bug or it just happened to be there when the thread dump happened.
If it happens again I'd to see if the thread is blocked on the {{Throwable.fillInStackTrace()}} native method again. Or if you have a way to reproduce that would be even better and I can test it :)
> Deadlock while logging
> ----------------------
>
> Key: WFLY-3620
> URL: https://issues.jboss.org/browse/WFLY-3620
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.1.0.Final
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (JGRP-1866) Broken Links on JBoss.org
by Daniel Coughlin (JIRA)
Daniel Coughlin created JGRP-1866:
-------------------------------------
Summary: Broken Links on JBoss.org
Key: JGRP-1866
URL: https://issues.jboss.org/browse/JGRP-1866
Project: JGroups
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Daniel Coughlin
Assignee: Bela Ban
The following broken link is currently listed against this project on www.jboss.org/projects.
git@github.com:belaban/JGroups.git - Committer Git
If you maintain a project.properties file that you have told the jboss.org team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3702) RetryInvoker is useless within the context of a transaction.
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3702:
----------------------------------
Summary: RetryInvoker is useless within the context of a transaction.
Key: WFLY-3702
URL: https://issues.jboss.org/browse/WFLY-3702
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 8.2.0.CR1, 9.0.0.Beta1
RetryInvoker should not retry if a given operation is transactional. If the operation fails - the status of the current transaction will be rollback-only, which will fail due to invalid transaction status if retried.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months