January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6230) Remoting "Read timed out" when starting multiple servers on a host

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6230?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6230: ---------------------------------------------- Osamu Nagano <onagano(a)redhat.com> made a comment on [bug 903453|https://bugzilla.redhat.com/show_bug.cgi?id=903453] The fix is already included in the upstream by AS7-6230 into 7.2.0.CR1. So I close this as targeted to EAP 6.1.0.CR1 too. > Remoting "Read timed out" when starting multiple servers on a host > ------------------------------------------------------------------ > > Key: AS7-6230 > URL: https://issues.jboss.org/browse/AS7-6230 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 7.2.0.CR1 > > > Apparently when starting multiple servers on a host some of them fail to connect to the HC and the remote connection times out. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6230) Remoting "Read timed out" when starting multiple servers on a host

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6230?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6230: ---------------------------------------------- Osamu Nagano <onagano(a)redhat.com> changed the Status of [bug 903453|https://bugzilla.redhat.com/show_bug.cgi?id=903453] from NEW to CLOSED > Remoting "Read timed out" when starting multiple servers on a host > ------------------------------------------------------------------ > > Key: AS7-6230 > URL: https://issues.jboss.org/browse/AS7-6230 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 7.2.0.CR1 > > > Apparently when starting multiple servers on a host some of them fail to connect to the HC and the remote connection times out. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5501) provide means to specify allowed ciphers for management https or change default to exclude weak ciphers

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-5501?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on AS7-5501: ---------------------------------- [~michaelyaakoby] this issue is about https cipher configuration for management web interface. aka the internal web server that serves admin console and rest api. And has noting to do with web subsystem, which is what you are using and successfully configuring. > provide means to specify allowed ciphers for management https or change default to exclude weak ciphers > ------------------------------------------------------------------------------------------------------- > > Key: AS7-5501 > URL: https://issues.jboss.org/browse/AS7-5501 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management, Security > Affects Versions: 7.1.2.Final (EAP) > Reporter: R Stokoe > Assignee: Darran Lofthouse > Fix For: 7.3.0.Alpha1 > > > Provide means to specify allowed ciphers for management https. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5501) provide means to specify allowed ciphers for management https or change default to exclude weak ciphers

by Michael Yakobi (JIRA)

[ https://issues.jboss.org/browse/AS7-5501?page=com.atlassian.jira.plugin.s... ] Michael Yakobi commented on AS7-5501: ------------------------------------- I'm confused - according to http://docs.jboss.org/jbossweb/7.0.x/config/ssl.html, I can specify "ciphers" in the SSL configuration to restrict the supported cipher suites. However, when I try this boot fails saying "ciphers" is unexpected attribute. So I tried using "cipher-suite" instead of "cipher" and it worked - using the following configuration I was able to remove support of weak ciphers: {code:xml} <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="ssl" password="changeit" certificate-key-file="${jboss.server.config.dir}/wfa.keystore" cipher-suite="TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" protocol="TLSv1" verify-client="false"/> </connector> <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost"/> </virtual-server> </subsystem> {code} > provide means to specify allowed ciphers for management https or change default to exclude weak ciphers > ------------------------------------------------------------------------------------------------------- > > Key: AS7-5501 > URL: https://issues.jboss.org/browse/AS7-5501 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management, Security > Affects Versions: 7.1.2.Final (EAP) > Reporter: R Stokoe > Assignee: Darran Lofthouse > Fix For: 7.3.0.Alpha1 > > > Provide means to specify allowed ciphers for management https. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6397) Cluster Environment Web Session Locks

by Manuel Pinto (JIRA)

Manuel Pinto created AS7-6397: --------------------------------- Summary: Cluster Environment Web Session Locks Key: AS7-6397 URL: https://issues.jboss.org/browse/AS7-6397 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.1.Final Environment: Windows 7 64bits, 8 GB RAM Reporter: Manuel Pinto Assignee: Paul Ferraro Hi, I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode. Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown: Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success. 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439) at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372) at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] ... 12 more The standalone-ha.xml "web" cache-container config is the following: <cache-container name="web" aliases="standard-session-cache" default-cache="repl"> <transport lock-timeout="60000"/> <replicated-cache name="repl" mode="SYNC" batching="true"> <file-store/> </replicated-cache> <replicated-cache name="sso" mode="SYNC" batching="true"/> <distributed-cache name="dist" mode="ASYNC" batching="true"> <file-store/> </distributed-cache> </cache-container> Thanks, Manuel Pinto -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-2152) WSDL URL should be anchor

by Guillaume Grossetie (JIRA)

[ https://issues.jboss.org/browse/AS7-2152?page=com.atlassian.jira.plugin.s... ] Guillaume Grossetie commented on AS7-2152: ------------------------------------------ Hi Harald, I've done almost the same thing but I wanted to test against the item type (AnchorItem) and never found out how to retrieve that information in the render() method. Anyway, I've just synced my workspace and will test it out, thanks :) > WSDL URL should be anchor > ------------------------- > > Key: AS7-2152 > URL: https://issues.jboss.org/browse/AS7-2152 > Project: Application Server 7 > Issue Type: Enhancement > Components: Console > Reporter: Richard Opalka > Assignee: Harald Pehl > Fix For: 7.3.0.Alpha1 > > -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-6319: ----------------------------------- FYI - A lot of other WS tests (like org.jboss.as.test.integration.ws.context.as1605.BothPojoAndEjbInWarTestCase.testPOJOEndpoint) too have started failing regularly with the same Socket Closed exception: {quote} Caused by: java.net.SocketException: SocketException invoking http://[0:0:0:0:0:0:0:1]:8080/as1605-customized/POJOEndpoint: Socket Closed at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1467) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1452) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:659) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134) ... 85 more 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) at sun.net.www.http.HttpClient.New(HttpClient.java:273) at sun.net.www.http.HttpClient.New(HttpClient.java:310) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:923) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1410) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1351) at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47) at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1424) ... 95 more {quote} > 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6393) Update commons-codec version to 1.6

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/AS7-6393?page=com.atlassian.jira.plugin.s... ] Josef Cacek commented on AS7-6393: ---------------------------------- It seems, the simple version upgrade breaks something somewhere... domain tests fail or freeze. https://github.com/jbossas/jboss-as/pull/3935 > Update commons-codec version to 1.6 > ----------------------------------- > > Key: AS7-6393 > URL: https://issues.jboss.org/browse/AS7-6393 > Project: Application Server 7 > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Apache HttpClient (4.2.1) library depends on commons-codec version 1.6, but we use only a version 1.4 now which is not fully compatible - e.g. changed behavior of the default constructor in Base64 class (chunked/not-chunked). > The problem is then in HttpClient's SPNEGO authentication. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3698) Improper parsing of right parenthesis in rule consequence

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3698?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3698. ---------------------------------- Fix Version/s: 6.0.0.Alpha2 Resolution: Done fixed in mvel 2.1.4 > Improper parsing of right parenthesis in rule consequence > --------------------------------------------------------- > > Key: JBRULES-3698 > URL: https://issues.jboss.org/browse/JBRULES-3698 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core (expert) > Affects Versions: 5.2.0.Final, 5.4.0.Final, 5.5.0.Final > Reporter: Chris Beesley > Assignee: Mario Fusco > Fix For: 6.0.0.Alpha2 > > > The right parenthesis is improperly parsed when creating a new object: > rule "Test Rule" > dialect "mvel" > when > Person() > then > SuggestedAction s = new SuggestedAction("suggest something with ) a paren") > end > This happens any time you use a new object declaration. It appears to blindly use the parenthesis without considering the quote which results in the following error message during rule compile: > [Error: unterminated string literal] > The following syntax compiles without problems: > rule "Test Rule" > dialect "mvel" > when > Person() > then > SuggestedAction sa = new SuggestedAction("Now no parens here") > sa.putValue("RELEVENCE", "with a ) paren ") > System.out.println(“I am a ) paren ”) > end > Using a left parenthesis does not cause an error. Switching to java dialect does not cause the error. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3698) Improper parsing of right parenthesis in rule consequence

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3698?page=com.atlassian.jira.plug... ] Mario Fusco reassigned JBRULES-3698: ------------------------------------ Assignee: Mario Fusco (was: Mark Proctor) > Improper parsing of right parenthesis in rule consequence > --------------------------------------------------------- > > Key: JBRULES-3698 > URL: https://issues.jboss.org/browse/JBRULES-3698 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core (expert) > Affects Versions: 5.2.0.Final, 5.4.0.Final, 5.5.0.Final > Reporter: Chris Beesley > Assignee: Mario Fusco > > The right parenthesis is improperly parsed when creating a new object: > rule "Test Rule" > dialect "mvel" > when > Person() > then > SuggestedAction s = new SuggestedAction("suggest something with ) a paren") > end > This happens any time you use a new object declaration. It appears to blindly use the parenthesis without considering the quote which results in the following error message during rule compile: > [Error: unterminated string literal] > The following syntax compiles without problems: > rule "Test Rule" > dialect "mvel" > when > Person() > then > SuggestedAction sa = new SuggestedAction("Now no parens here") > sa.putValue("RELEVENCE", "with a ) paren ") > System.out.println(“I am a ) paren ”) > end > Using a left parenthesis does not cause an error. Switching to java dialect does not cause the error. -- 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

13 years, 5 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 January 2013