January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5132) Jboss 4.2.2 JSF RI did not work for clicking links w/ target=_blank

by Dave Chen (JIRA)

Jboss 4.2.2 JSF RI did not work for clicking links w/ target=_blank ------------------------------------------------------------------- Key: JBAS-5132 URL: http://jira.jboss.com/jira/browse/JBAS-5132 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: JBossAS-4.2.2.GA Environment: Linux Federa Core 6, MySQL Reporter: Dave Chen Assigned To: Stan Silvert Priority: Critical Everything works fine for myfaces on Jboss 4.0.5GA. After I moved to JBoss 4.2.2 with faces RI. I got issues when clicking a command link with target=_blank. First time clicking the link is ok, but clicking the link again did not work, did not go to the Invoke Application phase to execute action. http://www.nabble.com/Jboss-4.2.2-RI-did-not-work-for-clicking-links-w--t... -- 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

18 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1210) Simple messaging test unable to drive CPU utilization better than 20%

by P Duffy (JIRA)

Simple messaging test unable to drive CPU utilization better than 20% --------------------------------------------------------------------- Key: JBMESSAGING-1210 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1210 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.3.0.GA Environment: EAP 4.2 running JBoss Messaging 1.3. Solaris 10 running on Sun T2000 server. Note that T2000 is able to run 32 threads concurrently. We routinely run various tests to confirm AS is fully utilizing available CPU. Reporter: P Duffy Assigned To: Tim Fox After several months, we have been unable to resolve a JBM performance issue. Recent JBoss consultant visit has not helped. We narrowed down our performance test to the following: - several instances of a multi threaded test client sending a simple ObjectMessage into a single AS instance. - a single MDB is deployed in the AS instance. This MDB consumes the message and throws it away (does nothing with it). When this test is run, the AS instance indicates messages are backing up in the Q, yet the clients are unable to drive the CPU past 20% utilization. We've tried the following tuning adjustments: (1) maxSession Annotation on MDB: @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "300") (2) maxSize in server/default/deploy/ejb3-interceptors-aop.xml, on Message Driven Bean: @org.jboss.annotation.ejb.PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=300, timeout=10000) (3) maxPoolSize and numAcceptThreads in server/default/deploy/jboss-messaging.sar/remoting-service.xml <attribute name="maxPoolSize" isParam="true">300</attribute> <attribute name="numAcceptThreads" isParam="true">50</attribute> (4) maxPoolSize in ThreadPool in /server/default/conf/jboss-service.xml <attribute name="MaximumPoolSize">800</attribute> Specific documentation re: JBM performance tuning is utterly lacking. We have tried to piece together various shreds of configuration from support cases, consultant comments, etc. to no avail. We need SPECIFIC direction from JBoss re: how to properly configure messaging to fully utilize available CPU. Else identify underlying bugs and resolve same. P.S. We have performed some examination of the JBM 1.3 code. With the huge caveat that we are not expert re: JBM internals, we have identified one location at which 100+ threads appear to be waiting on a single threaded synchronization point. See below. -----Original Message----- From: Mickael Graham (mickaelg) Sent: Monday, December 17, 2007 5:21 PM To: Nick Culpepper (nculpepp) Subject: Re: Thread dump for MDBEcho test Yes. Heaps of threads are blocked on this: at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServe rInvocationHandler.java:105) - waiting to lock <0xfffffffeb17129b8> (a java.lang.Class) This is where the performance problem is. Looking at the JBoss messaging code: public Object invoke(InvocationRequest invocation) throws Throwable { if (trace) { log.trace("invoking " + invocation); } synchronized (JMSServerInvocationHandler.class) { if (closed) { throw new MessagingJMSException("Cannot handle invocation since messaging server is not active (it is either starting up or shutting down)"); } RequestSupport request = (RequestSupport)invocation.getParameter(); if (request instanceof ConnectionFactoryCreateConnectionDelegateRequest) { //Create connection request ConnectionFactoryCreateConnectionDelegateRequest cReq = (ConnectionFactoryCreateConnectionDelegateRequest)request; String remotingSessionId = cReq.getRemotingSessionID(); ServerInvokerCallbackHandler callbackHandler = null; synchronized(callbackHandlers) { callbackHandler = (ServerInvokerCallbackHandler)callbackHandlers.get(remotingSessionId); } if (callbackHandler != null) { log.debug("found calllback handler for remoting session " + Util.guidToString(remotingSessionId)); cReq.setCallbackHandler(callbackHandler); } else { throw new IllegalStateException("Cannot find callback handler " + "for session id " + remotingSessionId); } } return request.serverInvoke(); } } Basically this is for delivering I believe and that looks single threaded. Perhaps once its delivered, it will not be single threaded. -- 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

18 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1211) Investigate Paging on cluster

by Clebert Suconic (JIRA)

Investigate Paging on cluster ----------------------------- Key: JBMESSAGING-1211 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1211 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Tim Fox -- 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

18 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBREM-753) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-753 URL: http://jira.jboss.com/jira/browse/JBREM-753 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Critical Fix For: 2.4.0.CR1 (Pinto) Each version of Remoting must be API and wire compatible with earlier versions, at least as far back as 1.4.3.GA, which is used in JBossAS 4.0.4.GA and 4.0.5.GA. -- 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

18 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-703) allow for total configuration of socket via socket invoker

by Tom Elrod (JIRA)

allow for total configuration of socket via socket invoker ---------------------------------------------------------- Key: JBREM-703 URL: http://jira.jboss.com/jira/browse/JBREM-703 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.0.Alpha7 Reporter: Tom Elrod Assigned To: Tom Elrod Priority: Minor Fix For: 2.2.0.Beta2 (Bluto) Currently remoting does not expose all the configuration properties for a socket for the socket invokers. Should just allow configuration of everything allowed by the jdk api for a socket to be allowed via remtoing (i.e. sendBufferSize and receiveBufferSize) -- 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

18 years, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-739) Fix java serialization leak.

by Ron Sigal (JIRA)

Fix java serialization leak. ---------------------------- Key: JBREM-739 URL: http://jira.jboss.com/jira/browse/JBREM-739 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.SP2 Bug was reported in JBAS-4359. -- 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

18 years, 6 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-809) Verify that the behavior of the HTTPUnMarshaller re stripping CR and LF characters is correct

by Tom Fennelly (JIRA)

Verify that the behavior of the HTTPUnMarshaller re stripping CR and LF characters is correct --------------------------------------------------------------------------------------------- Key: JBREM-809 URL: http://jira.jboss.com/jira/browse/JBREM-809 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: marshall Affects Versions: 2.2.2.GA Reporter: Tom Fennelly Assigned To: Trustin Lee At the moment, the HTTPUnMarshaller uses a BufferedReader to read a HTTP char stream. This causes it to modify the message payload by removing the CR and LF characters. This causes a problem for us on the ESB because it means that signature checks fail on signed SOAP messages since the sig was generated from the message containing the CR and LF chars. It's even worse than that... it actually corrupts the signature within the message because the canonical form of the sig contains CRLF chars. We got around this in the ESB (in the short term) by setting our own modified version of the HTTPUnMarshaller - one that doesn't use a BufferedReader. -- 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

18 years, 6 months

2
11
0 / 0

[JBoss JIRA] Created: (JBREM-842) Deprecate multiplex transport

by Ron Sigal (JIRA)

Deprecate multiplex transport ----------------------------- Key: JBREM-842 URL: http://jira.jboss.com/jira/browse/JBREM-842 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The multiplex transport has never been used in JBoss software, and Remoting 3.0 will offer connection multiplexing capabilities. -- 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

18 years, 6 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-864) CLONE -ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6

by Ron Sigal (JIRA)

CLONE -ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6 ------------------------------------------------------------------------------------------ Key: JBREM-864 URL: http://jira.jboss.com/jira/browse/JBREM-864 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Takayoshi Kimura Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 IPv6 address contains ":" character, so it cannot be used in ObjectName. 2007-10-18 15:37:40,476 WARN [org.jboss.remoting.transport.Connector] Error registering invoker SocketServerInvoker[UNINITIALIZED] with MBeanServer. javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:529) at javax.management.ObjectName.<init>(ObjectName.java:1304) at org.jboss.remoting.transport.Connector.init(Connector.java:402) at org.jboss.remoting.transport.Connector.create(Connector.java:760) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:330) at org.jboss.system.ServiceController.create(ServiceController.java:273) at org.jboss.system.ServiceController.create(ServiceController.java:349) at org.jboss.system.ServiceController.create(ServiceController.java:273) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.create(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:258) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:595) -- 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

18 years, 6 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-865) CLONE -Verify IPv6 addresses are handled correctly

by Ron Sigal (JIRA)

CLONE -Verify IPv6 addresses are handled correctly -------------------------------------------------- Key: JBREM-865 URL: http://jira.jboss.com/jira/browse/JBREM-865 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3 Need to make sure that Remoting can bind ServerSockets to IPv6 addresses. This issue is related to http://jira.jboss.com/jira/browse/JBREM-645. -- 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

18 years, 6 months

1
7
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 2008