[JBoss JIRA] (JBWEB-261) All http threads spin indefinetly consuming ~100% CPU
by sivaraman saminathan (JIRA)
[ https://issues.jboss.org/browse/JBWEB-261?page=com.atlassian.jira.plugin.... ]
sivaraman saminathan updated JBWEB-261:
---------------------------------------
Summary: All http threads spin indefinetly consuming ~100% CPU (was: All http threads spin indefinetely consuming ~100% CPU)
> All http threads spin indefinetly consuming ~100% CPU
> -----------------------------------------------------
>
> Key: JBWEB-261
> URL: https://issues.jboss.org/browse/JBWEB-261
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-2.1.3.GA
> Environment: My issue happened on Solaris 10, JRE 1.6_26 & Jboss 5.1
> Reporter: sivaraman saminathan
> Assignee: Remy Maucherat
> Priority: Critical
>
> All http threads spin madly in a java.util.HashMap.getEntry indefinitely consuming 100% CPU. This issue is already reported and fixed in tomcat.
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> The issue has affected 2 times in our production systems and we had to restart the production systems to resolve the issue.
> Please integrate this fix in Jboss web 2.1.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBWEB-261) All http threads spin indefinetely consuming ~100% CPU
by sivaraman saminathan (JIRA)
sivaraman saminathan created JBWEB-261:
------------------------------------------
Summary: All http threads spin indefinetely consuming ~100% CPU
Key: JBWEB-261
URL: https://issues.jboss.org/browse/JBWEB-261
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tomcat
Affects Versions: JBossWeb-2.1.3.GA
Environment: My issue happened on Solaris 10, JRE 1.6_26 & Jboss 5.1
Reporter: sivaraman saminathan
Assignee: Remy Maucherat
Priority: Critical
All http threads spin madly in a java.util.HashMap.getEntry indefinitely consuming 100% CPU. This issue is already reported and fixed in tomcat.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
The issue has affected 2 times in our production systems and we had to restart the production systems to resolve the issue.
Please integrate this fix in Jboss web 2.1.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6387) Improper error handling when attempting to remove a server-config with a running server
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/AS7-6387?page=com.atlassian.jira.plugin.s... ]
Osamu Nagano commented on AS7-6387:
-----------------------------------
HOW TO REPRODUCE:
This is easy to reproduce using the default domain.xml/host.xml configuration of 7.1.3.Final (EAP 6.0.1).
1. Edit the host.xml so that all servers 'auto-start' to be 'false'.
2. Execute domain.sh. Only the process controller and the domain controller are started.
3. In the jboss-cli.sh, try to remove a server-config then you'll get the error.
[domain@localhost:9999 /] /host=master/server-config=server-three:remove
{
"outcome" => "failed",
"result" => {
"outcome" => "failed",
"failure-description" => "[core-service, path, server-config, system-property, jvm, interface]",
"rolled-back" => true
},
"rolled-back" => true
}
4. If there are any running servers, the remove command succeeds as expected.
[domain@localhost:9999 /] /host=master/server-config=server-one:start
{
"outcome" => "success",
"result" => "STARTING"
}
[domain@localhost:9999 /] /host=master/server-config=server-three:remove
{
"outcome" => "success",
"result" => {"outcome" => "success"}
}
> Improper error handling when attempting to remove a server-config with a running server
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6387
> URL: https://issues.jboss.org/browse/AS7-6387
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Trying to remove the config for server-one while it's still running produces an uninformative failure:
> [domain@localhost:9999 /] /host=master/server-config=server-one:remove
> {
> "outcome" => "failed",
> "result" => undefined,
> "rolled-back" => true,
> "server-groups" => undefined
> }
> An EAP 6 user reported a similar problem but with a different response:
> [domain@localhost:9999 /] /host=xyz/server-config=as1:remove
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "[core-service, path, server-config, system-property, jvm, interface]",
> "rolled-back" => true
> },
> "failure-description" => undefined
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6413?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6413:
---------------------------------------
It's perfectly valid to fail the remove() op in Stage.MODEL if children haven't been removed first. If cleaning up the runtime services proves troublesome to get done this week, failing the op is an option.
> Remove subsystem command in JGroups management api should remove existing stacks.
> ---------------------------------------------------------------------------------
>
> Key: AS7-6413
> URL: https://issues.jboss.org/browse/AS7-6413
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 7.2.0.Alpha1
>
>
> The management command
> {noformat}
> /subsystem=jgroups:remove()
> {noformat}
> should check for existing stack children and remove their runtime services before removing its own runtime services.
> Otherwise removing the JGroups subsystem, followed by adding it back in and creating a new stack with the same name will fail due to duplicate MSC services associated with the stack.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-6408:
------------------------------------------
Bernd
Thank you for pointing out this issue and providing the scripts.
I have reproduced it myself and will be investigating asap.
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Richard Achmatowicz
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6410) Session beans are not bound to JNDI if there is a remote interface for a stateless bean
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6410?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6410:
-------------------------------------
This appears to be working against upstream.
> Session beans are not bound to JNDI if there is a remote interface for a stateless bean
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6410
> URL: https://issues.jboss.org/browse/AS7-6410
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming, Remoting
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10
> Reporter: Jari Juslin
> Assignee: jaikiran pai
> Attachments: bugrepro.zip
>
>
> I have a session bean inside a jar, which in turn is inside an ear. If the session bean's interface is market with @Remote, JBoss 7.1.1 does not bind any beans in the package to JNDI. Change the @Remote to @Local or comment it out and binding takes place.
> The binding was checked both programmatically and from JBoss Management Console.
> No errors messages are printed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6413?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz reassigned AS7-6413:
----------------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> Remove subsystem command in JGroups management api should remove existing stacks.
> ---------------------------------------------------------------------------------
>
> Key: AS7-6413
> URL: https://issues.jboss.org/browse/AS7-6413
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 7.2.0.Alpha1
>
>
> The management command
> {noformat}
> /subsystem=jgroups:remove()
> {noformat}
> should check for existing stack children and remove their runtime services before removing its own runtime services.
> Otherwise removing the JGroups subsystem, followed by adding it back in and creating a new stack with the same name will fail due to duplicate MSC services associated with the stack.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6319:
---------------------------------------
On Tomaz' server we use for testing Windows builds, this started failing immediately after a JDK update to u38. Tomaz just reverted that and we'll see if that fixes the issue. There was a lightning JDK update on Jan 10 which vague memory tells me is about when this started happening there. This JIRA was created the 11th, so that fits.
This all ties into the notion that this is related to the discussion at http://stackoverflow.com/questions/14270311/rather-mysterious-socketexcep....
u38 had changes to HttpClient:
stuartdouglas: http://www.oracle.com/technetwork/java/javase/2col/6u38-bugfixes-1880999....
stuartdouglas: "Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases"
> EJBEndpointAuthenticationTestCase is failing intermittently
> ------------------------------------------------------------
>
> Key: AS7-6319
> URL: https://issues.jboss.org/browse/AS7-6319
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.2.0.Alpha1
> Environment: AS7 upstream (Jan 11 2013)
> Reporter: jaikiran pai
> Assignee: Jim Ma
> Attachments: log.txt
>
>
> The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
> {code}
> java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
> {code}
> same goes also for PojoEndpointAuthenticationTestCase that fails sometimes
> {code}
> javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at $Proxy110.hello(Unknown Source)
> at org.jboss.as.test.integration.ws.authentication.PojoEndpointAuthenticationTestCase.accessHelloWithValidUser1(PojoEndpointAuthenticationTestCase.java:116)
> ...
> Caused by: java.net.SocketException: Socket Closed
> at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
> at java.net.Socket.getSoTimeout(Socket.java:1032)
> at sun.net.www.http.HttpClient.available(HttpClient.java:356)
> {code}
> It looks like the testcase expects a specific text in the exception cause.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-6413:
----------------------------------------
Summary: Remove subsystem command in JGroups management api should remove existing stacks.
Key: AS7-6413
URL: https://issues.jboss.org/browse/AS7-6413
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.2.0.Alpha1
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Fix For: 7.2.0.Alpha1
The management command
{noformat}
/subsystem=jgroups:remove()
{noformat}
should check for existing stack children and remove their runtime services before removing its own runtime services.
Otherwise removing the JGroups subsystem, followed by adding it back in and creating a new stack with the same name will fail due to duplicate MSC services associated with the stack.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6262) Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/AS7-6262?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on AS7-6262:
-----------------------------------
Mojarra issue http://java.net/jira/browse/JAVASERVERFACES-2703
> Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
> ----------------------------------------------------------------------------------
>
> Key: AS7-6262
> URL: https://issues.jboss.org/browse/AS7-6262
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2013-01-02 be583f5)
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: AS7-6262.tar.gz, AS7-6262.war, reproducer-pure.tar.gz, reproducer-pure.war, reproducer.tar.gz, reproducer.war
>
>
> Dynamically created converters seems to be ignored in some special cases, like the following.
> Having a form like this:
> {code}
> <h:form>
> <ul>
> <ui:repeat value="#{basket.items}" var="i">
> <li>Item #{i.number}
> <h:selectOneMenu value="#{i.color}">
> <test:selectColors />
> </h:selectOneMenu>
> </li>
> </ui:repeat>
> </ul>
> <div>
> <h:commandButton value="Add" action="#{basket.add}" />
> </div>
> <h:outputText value="#{basket.string}" />
> </h:form>
> {code}
> Where SelectColors is
> {code}
> @JsfComponent(description=@Description(displayName="org.jboss.seam.test.SelectColors",value="Creates a List<SelectItem> of colors."),
> family="javax.faces.SelectItems", type="org.jboss.seam.test.SelectColors",generate="org.jboss.seam.test.html.HtmlSelectColors",
> tag = @Tag(baseClass="javax.faces.webapp.UIComponentTagBase", name="selectColors"))
> public class SelectColors extends javax.faces.component.UISelectItems implements SystemEventListener {
> public SelectColors() {
> FacesContext context = FacesContext.getCurrentInstance();
> UIViewRoot root = context.getViewRoot();
> root.subscribeToViewEvent( PreRenderViewEvent.class, this );
> }
> @Override
> public Object getValue() {
> List<SelectItem> ret = new LinkedList<SelectItem> ();
> ret.add(new SelectItem("default", "Select color... (black by default)"));
> ret.add(new SelectItem("red", "Red"));
> ret.add(new SelectItem("white", "White"));
> ret.add(new SelectItem("blue", "Blue"));
> ret.add(new SelectItem("black", "Black"));
> return ret;
> }
> private void addSelectionConverter() {
> UIComponent parentComponent = getParent();
> if (parentComponent instanceof ValueHolder) {
> ValueHolder parentValueHolder = (ValueHolder) parentComponent;
> Converter parentConverter = parentValueHolder.getConverter();
> if (parentConverter == null) {
> parentValueHolder.setConverter(new DefaultColorConverter());
> }
> }
> }
> @Override
> public void processEvent(SystemEvent event) throws AbortProcessingException
> {
> if ( !FacesContext.getCurrentInstance().isPostback() ) {
> addSelectionConverter();
> }
> }
> @Override
> public boolean isListenerForSource(Object source)
> {
> return ( source instanceof UIViewRoot );
> }
> }
> {code}
> and the DefaultColorConverter being:
> {code}
> @FacesConverter(value="org.jboss.seam.test.DefaultColorConverter")
> public class DefaultColorConverter implements Converter
> {
> public static final String DEFAULT_COLOR = "black";
> public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
> {
> if ("default".equals(value)) {
> return DEFAULT_COLOR;
> }
>
> return value;
> }
> public String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException
> {
> return value.toString();
> }
> }
> {code}
> In the pre-Mojarra 2.1.16 upgrade, clicking on the add button repeatedly creates "black" items. Post mojarra 2.1.16, it sets the color to "default", which should never happen, as the converter should convert the "default" value into "black".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months