December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-919) PojoCache to optimize access to __JBossInternal__ region

by Ben Wang (JIRA)

PojoCache to optimize access to __JBossInternal__ region -------------------------------------------------------- Key: JBCACHE-919 URL: http://jira.jboss.com/jira/browse/JBCACHE-919 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.ALPHA2 This is discovered during test for PojoCache. Currently, all external POJOs are mapped into __JBossInternal__ region nodes. This creates a synchronizatio bottleneck for the __JBossInternal__ fqn as all newly created node will need to obtain a WL on __JBossInternal__ and therefore concurrency will suffer. Solution is to pre-create the internal node such as /__JBossInternal__/xxjksla without going throu the interceptor (using Option to skip it). This way, during normal POJO attach, only RL is needed from __JBossInternal__ node. -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-917) JBCMethodCall serial version uid incompatibility with other 1.4.0.x releases

by Manik Surtani (JIRA)

JBCMethodCall serial version uid incompatibility with other 1.4.0.x releases ---------------------------------------------------------------------------- Key: JBCACHE-917 URL: http://jira.jboss.com/jira/browse/JBCACHE-917 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 1.4.1.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

17 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-183) Fix bug in interposed coordinator after_completion warning message

by Mark Little (JIRA)

Fix bug in interposed coordinator after_completion warning message ------------------------------------------------------------------ Key: JBTM-183 URL: http://jira.jboss.com/jira/browse/JBTM-183 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.2.2 Reporter: Mark Little Assigned To: Mark Little Priority: Trivial Fix For: 4.2.3 If the parent completion status is not the same as the interposed coordinator's then it prints a warning along with the two statuses. However, it doesn't use the utility to convert from the CORBA status objects to the meaningful string. Fix this. -- 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

17 years, 10 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-127) Delayed delivery, redelivery count and pluggable expiration behavior

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-127?page=all ] Tim Fox reassigned JBMESSAGING-127: ----------------------------------- Assignee: Tim Fox > Delayed delivery, redelivery count and pluggable expiration behavior > -------------------------------------------------------------------- > > Key: JBMESSAGING-127 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-127 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core, JMS Facade > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.0.Beta2 > > Original Estimate: 1 week, 2 days > Remaining Estimate: 1 week, 2 days > -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-355) Remove possibility of delivery race conditions

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ] Tim Fox closed JBMESSAGING-355. ------------------------------- Resolution: Won't Fix Channel no longer maintains deliveries, making this race conditions impossible to happen now :) > Remove possibility of delivery race conditions > ---------------------------------------------- > > Key: JBMESSAGING-355 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-355 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > Attachments: race-condition.log > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently race conditions can occur on message delivery where the delivery is acknowledged or cancelled before the call to handle has returned. > In ChannelState we defensively program against this by synchronizing on the returned delivery and by dealing with the situation where the delivery does not exist in the channel state and ignoring. > See ChannelSupport::deliver() and ChannelState.cancelDelivery. > This approach has the following problems: > Complexity of code to maintain and understand. > Where acks return quickly we are likely to get contention on the lock in ChannelSupport::deliver, thus reducing throughput. > A much simpler solution enables us to remove the possibility of such race conditions and remove the corresponding lock contention. > This can be done by adding a confirm() method on Delivery. > When the receiver receives the message in it's handle() call, before dispatching the message it calls Delivery::confirm. This results in the channel adding the delivery to the channel state. Thus we can be assured that the delivery exists before any acknowledgment or cancellation comes in. > This is a very simple change. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-257) Optimisation for deliveries immediately returned as done

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-257?page=all ] Tim Fox closed JBMESSAGING-257. ------------------------------- Resolution: Won't Fix Channel no longer stores deliveries making this irrelevant > Optimisation for deliveries immediately returned as done > -------------------------------------------------------- > > Key: JBMESSAGING-257 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-257 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Optional > Fix For: 1.2.1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Optimisation: If a delivery is returned as done. There is no need to first store the reference in the channel state as is currently the case. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-327) Improve concurrency for acknowledgement

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-327?page=all ] Tim Fox closed JBMESSAGING-327. ------------------------------- Resolution: Won't Fix Channel no longer maintains deliveries making this irrelevant > Improve concurrency for acknowledgement > --------------------------------------- > > Key: JBMESSAGING-327 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-327 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Improve concurrency in acknnowledgment by using ConcurrentHashSet for deliveries and removing delivery lock -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-140) Move responsibility for management of delivery list from receiver into channel

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-140?page=all ] Tim Fox closed JBMESSAGING-140. ------------------------------- Resolution: Won't Fix The channel no longer maintains deliveries - so this is now defunct. > Move responsibility for management of delivery list from receiver into channel > ------------------------------------------------------------------------------ > > Key: JBMESSAGING-140 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-140 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.CR1 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Currently each receiver has the responsibility for managing it's list of deliveries. This is to avoid a race condition whereby the message can be acked before the call to handle has returned. > This is a high burden of responsibility for the receiver and results in a lot of unnecessary code in the receiver implementation, plus an extra hashmap lookup > We should consider whether we can give the responsibiltty to the channel. > We could still acknowledge and cancel throught the delivery object, by creating one when required and calling cancel/acknowledge on it. > the instance of delivery won't contain a message reference but just a message id. then inside delivery.cancel()/acknowledge(), it calls > channel.cancel(this) and the channel is smart enought to lookup the delivery/reference as required. > This won't require ANY changes to the receiver/channel interface and will allow us to get rid of the delivery list -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2861) HttpSession sharing between WAR modules

by Ajay Gupta (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2861?page=comments#action_12349388 ] Ajay Gupta commented on JBAS-2861: ---------------------------------- I would like to know the plans for delivering this change in terms of time. Could someone post that information here? > HttpSession sharing between WAR modules > --------------------------------------- > > Key: JBAS-2861 > URL: http://jira.jboss.com/jira/browse/JBAS-2861 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-4.2.0.CR1 > > > Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer. > Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB). > We need to divide this web module into several smaller web modules. > In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible. > The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not. > The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application. > The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A. > The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information: > WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht... > BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-702) Dead Lock condition on MessageCallbackHandler when failover is being executed

by Clebert Suconic (JIRA)

Dead Lock condition on MessageCallbackHandler when failover is being executed ----------------------------------------------------------------------------- Key: JBMESSAGING-702 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-702 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assigned To: Clebert Suconic If a failover happens when an auto ACK, is returned from MessageCallbackHandler (look at the thread dump) a dead lock might happen: LocalThreadConsumer-1" prio=1 tid=0x8b9cf568 nid=0x228e in Object.wait() [0x8a66f000..0x8a66feb0] at java.lang.Object.wait(Native Method) - waiting on <0x91652838> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:474) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(WriterPreferenceReadWriteLock.java:240) - locked <0x91652838> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.jboss.jms.client.container.ValveAspect.invoke(ValveAspect.java:107) at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117) at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java) at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68) at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java) at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) at org.jboss.jms.client.delegate.ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.invokeNext(ClientSessionDelegate$acknowledgeDelivery_N3172014476730533936.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.acknowledgeDelivery(ClientSessionDelegate.java) at org.jboss.jms.client.container.SessionAspect.ackDelivery(SessionAspect.java:453) at org.jboss.jms.client.container.SessionAspect.handlePostDeliver(SessionAspect.java:283) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect7.invoke(SessionAspect7.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117) at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java) at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68) at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java) at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_5319211143798977162.invokeNext(ClientSessionDelegate$postDeliver_5319211143798977162.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.postDeliver(ClientSessionDelegate.java) at org.jboss.jms.client.remoting.MessageCallbackHandler.receive(MessageCallbackHandler.java:419) - locked <0x91652338> (a java.lang.Object) at org.jboss.jms.client.container.ReceiverAspect.handleReceive(ReceiverAspect.java:63) at org.jboss.aop.advice.org.jboss.jms.client.container.ReceiverAspect25.invoke(ReceiverAspect25.java) at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:177) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117) at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java) at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:68) at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java) at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) at org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java) at org.jboss.jms.client.delegate.ClientConsumerDelegate.receive(ClientConsumerDelegate.java) at org.jboss.jms.client.JBossMessageConsumer.receive(JBossMessageConsumer.java:86) at org.jboss.test.messaging.jms.clustering.ValveTest$LocalThreadConsumer.run(ValveTest.java:94) "Thread-6" daemon prio=1 tid=0x08183840 nid=0x22d2 waiting for monitor entry [0x8aefc000..0x8aefd030] at org.jboss.jms.client.remoting.MessageCallbackHandler.copyState(MessageCallbackHandler.java:500) - waiting to lock <0x91652338> (a java.lang.Object) at org.jboss.jms.client.container.HAAspect.handleFailoverOnConsumer(HAAspect.java:605) at org.jboss.jms.client.container.HAAspect.performClientSideFailover(HAAspect.java:451) at org.jboss.jms.client.container.HAAspect.handleConnectionFailure(HAAspect.java:337) at org.jboss.jms.client.container.ValveAspect.handleConnectionFailure(ValveAspect.java:202) at org.jboss.jms.client.container.ValveAspect$ConnectionFailureListener.handleConnectionException(ValveAspect.java:241) at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:83) at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:139) -- 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

17 years, 10 months

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006