December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-810) coyote.RequestMap not storing all request properties in the Map.Entry set

by Tom Fennelly (JIRA)

coyote.RequestMap not storing all request properties in the Map.Entry set ------------------------------------------------------------------------- Key: JBREM-810 URL: http://jira.jboss.com/jira/browse/JBREM-810 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.1.GA Reporter: Tom Fennelly Assigned To: Trustin Lee Priority: Minor Small thing, but the RequestMap overrides the get method for some of the request properties e.g. "Path" and "HttpVersion". This is fine if the code using the request Map (from InvocationRequest) accesses the properties via the get method. However, if it iterates over the Map.Entry set, these values will come back as null because they're not actually stored in the map entry set. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1702) Hibernate/JBoss Cache locking issues seem to be occurring in the HA setup

by Sohil Shah (JIRA)

Hibernate/JBoss Cache locking issues seem to be occurring in the HA setup ------------------------------------------------------------------------- Key: JBPORTAL-1702 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1702 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.1 Final, 2.6 Final Reporter: Sohil Shah Assigned To: Sohil Shah When the Portal is run in a clustered environment, I have noticed some locking issues in the Hibernate Cache which is using JBoss Cache as the caching engine. So far, the locks have been detected on the HibernateUserModuleImpl in the Identity Module Steps to Reproduce: 1/ Start up both cluster nodes 2/ Login in to node1 with admin user 3/ Login in to node2 with admin user 4/ Logout of node1 5/ Try to Logout of node2, and you see locking errors on node2 -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5083) Add the transaction active check to the jdbc resource adapter

by Adrian Brock (JIRA)

Add the transaction active check to the jdbc resource adapter ------------------------------------------------------------- Key: JBAS-5083 URL: http://jira.jboss.com/jira/browse/JBAS-5083 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA Add the new transaction active to the jdbc resource adapter. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5084) Add the transaction active check to the jms resource adapter

by Adrian Brock (JIRA)

Add the transaction active check to the jms resource adapter ------------------------------------------------------------ Key: JBAS-5084 URL: http://jira.jboss.com/jira/browse/JBAS-5084 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA Add the new transaction active to the jdbc resource adapter. -- 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, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-5080) Need to check transaction status on SQL operations

by Adrian Brock (JIRA)

Need to check transaction status on SQL operations -------------------------------------------------- Key: JBAS-5080 URL: http://jira.jboss.com/jira/browse/JBAS-5080 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA In 4.2.x the transaction timeout rollsback the transaction rather than marking it rollback only. This means that for the local transaction datasource the connection has effectively moved onto the next transaction. Actual code: Connection c = datasource.getConnection(); // tx timeout here Statement s = createStatement(); s.executeUpdate(); // should not work Actual Code executed in 4.0.x Connection c = pool.getConnection(); // tx timeout here transaction.setRollbackOnly(); Statement s = createStatement(); s.executeUpdate(); tx.rollback(); // Rollsback the update Actual Code executed in 4.2.x Connection c = pool.getConnection(); // tx timeout here transaction.rollback(); Statement s = createStatement(); s.executeUpdate(); // happens "in the next local transaction" -- 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, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-5082) Add a transaction status interface for the connection manager and implement it in TxConnectionManager

by Adrian Brock (JIRA)

Add a transaction status interface for the connection manager and implement it in TxConnectionManager ------------------------------------------------------------------------------------------------------ Key: JBAS-5082 URL: http://jira.jboss.com/jira/browse/JBAS-5082 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA The ConnectionManager needs a transaction status interface such that resource adapters can check the active status of the transaction assoication. This should be similar to the TransactionTimeoutConfiguration where only the TxConnectionManager implements it. If the transaction is not active then an exception should be thrown. The resource adapters (jdbc and jms) need to add a check for transation active to their checkState methods). -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-479) Wizard for autopopulating a decision table

by Michael Neale (JIRA)

Wizard for autopopulating a decision table ------------------------------------------ Key: JBRULES-479 URL: http://jira.jboss.com/jira/browse/JBRULES-479 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Decision tables Reporter: Michael Neale Assigned To: Mark Proctor Priority: Minor This could be done quite easily by a contributor. Have a wizard (in the IDE) which takes information regarding the facts to be used, fields, actions (and the number of each) and generates a decision table based on that info capture (ie populates it). -- 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, 4 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, 4 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, 4 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, 4 months

1
3
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 December 2007