August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-852) Broken Links on JBoss.org

by Daniel Coughlin (JIRA)

Daniel Coughlin created SECURITY-852: ---------------------------------------- Summary: Broken Links on JBoss.org Key: SECURITY-852 URL: https://issues.jboss.org/browse/SECURITY-852 Project: PicketBox Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Daniel Coughlin Assignee: Stefan Guilhen The following broken link is currently listed against this project on www.jboss.org/projects. http://twitter.com/picketbox - Twitter Link http://community.jboss.org/en/jbossas/picketbox?view=discussions - User Forum http://community.jboss.org/en/jbossas/picketbox?view=discussions - Community http://community.jboss.org/en/jbossas/picketbox?view=documents - KnowledgeBase 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)

11 years, 11 months

1
0
0 / 0

[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)

11 years, 11 months

1
0
0 / 0

[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)

11 years, 11 months

1
0
0 / 0

[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)

11 years, 11 months

1
0
0 / 0

[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)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBSER-132) Broken Links on JBoss.org

by Daniel Coughlin (JIRA)

Daniel Coughlin created JBSER-132: ------------------------------------- Summary: Broken Links on JBoss.org Key: JBSER-132 URL: https://issues.jboss.org/browse/JBSER-132 Project: JBoss Serialization Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Daniel Coughlin Assignee: Clebert Suconic The following broken link is currently listed against this project on www.jboss.org/projects. http://www.jboss.org/feeds/view/serialization - Blog Link 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)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFCORE-37: ------------------------------------- The easiest workaround for this is to just add the handler in the {{add}} operation. The issue is how the operations are processed. The model is first updated which because the the {{add-handler}} operation adds the handler to the model. Then the runtime is updated and during the add of the logger, the handler is assigned to the logger because it's in the model. This results in the {{add-handler}} failing as the {{add}} operation for the {{root-logger=ROOT}} resource already added the runtime change for the handler. > Batching logging profile creation CLI commands can cause errors > --------------------------------------------------------------- > > Key: WFCORE-37 > URL: https://issues.jboss.org/browse/WFCORE-37 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > > Given these set of commands: > {noformat} > /subsystem=logging/logging-profile=myLoggingProfile:add > /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"}) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler) > /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO) > {noformat} > If I run those in a batch, I get an error: > {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([ > ("subsystem" => "logging"), > ("logging-profile" => "myLoggingProfile"), > ("root-logger" => "ROOT") > ]) - failure description: "JBAS011536: Handler myHandler is already assigned." > {noformat} > If I run each one individually, I get no error. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBBUILD-737) Broken Link on JBoss.org

by Daniel Coughlin (JIRA)

Daniel Coughlin created JBBUILD-737: --------------------------------------- Summary: Broken Link on JBoss.org Key: JBBUILD-737 URL: https://issues.jboss.org/browse/JBBUILD-737 Project: JBoss Build System Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Daniel Coughlin Assignee: Paul Gier The following broken link is currently listed against this project on www.jboss.org/projects. http://fisheye.jboss.org/repos/jbossbuild/trunk - Fisheye Link 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)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3670: ----------------------------------- Oh, well in that case, I'd say you're simply doing it wrong: the shared stuff should not be in a module at all, just in a filesystem JAR. Then, you add the filesystem JAR in to each deployment as a resource root. > Flag modules to be loaded in a distinct classloader context > ----------------------------------------------------------- > > Key: WFLY-3670 > URL: https://issues.jboss.org/browse/WFLY-3670 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications. > An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide. > There are two possiblities to flag that > - within the module.xml > - within the module reference MAIFEST or jboss-deployment-structure.xml -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-38) Add additional password algorithms to WildFlyElytronPasswordProvider

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-38: ----------------------------------- Summary: Add additional password algorithms to WildFlyElytronPasswordProvider Key: ELY-38 URL: https://issues.jboss.org/browse/ELY-38 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: API / SPI, Password Types Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 A number of algorithms are now supported, update 'WildFlyElytronPasswordProvider' so that these are also registered. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014