October 2006 - jboss-jira - Jboss List Archives

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

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ] Ovidiu Feodorov updated JBMESSAGING-355: ---------------------------------------- Fix Version/s: 1.0.2.CR1 (was: 1.2.1) This race condition affects 1.0.1.GA. See http://cruisecontrol.jboss.com/cc/buildresults/jms-1.0-testsuite?log=log2... Clebert's comments: It is a race condition between delivery and cancelDeliveries... The delivery (on server side) is being incremented at ChannelSupport/deliveryInternal CancelDelivery (SimpleDelivery) is not rolling back the reference count. > 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.0.2.CR1 > > 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

18 years, 2 months

1
0
0 / 0

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

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ] Ovidiu Feodorov updated JBMESSAGING-355: ---------------------------------------- Attachment: race-condition.log Attached the race condition snapshot. > 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.0.2.CR1 > > 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

18 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-790) NPE on getNotifier after cache instantiation

by Ben Wang (JIRA)

NPE on getNotifier after cache instantiation -------------------------------------------- Key: JBCACHE-790 URL: http://jira.jboss.com/jira/browse/JBCACHE-790 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Manik Surtani Fix For: 2.0.0 Consider the following scenario: cache = DefaultCacheFactory.createInstance(config, false); // not to start cache lifecycle cache.getNotifier(); // return null becuase it is created in create() method call. I think we need to move the notifier creation to the constructor. -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-428) Hibernate Session closed in Seam produced component with session scope

by fguerzoni (JIRA)

Hibernate Session closed in Seam produced component with session scope ---------------------------------------------------------------------- Key: JBSEAM-428 URL: http://jira.jboss.com/jira/browse/JBSEAM-428 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: WIN XP SP2, jdk1.5.0_04, SEAM from CVS as 18 october 2006, Jetty-6.0.1, Tomcat-5.5.17. Seam is used configured to work in SE environment (with microcontainer) Reporter: fguerzoni I get org.hibernate.SessionException: Session is closed! when accessing my project home page. I've sligthly modified 'hibernate' example in order to match my use case. 1) The problem arises when home.xhtml is rendered and a Config javabean is created by Seam. ConfigBean has Session scope and tries to access database to get some infos. 2) The problem arises only when the entity that results from query has a relationship (eg one-to-many) to other entities. 3) The problem arises only when the object istance returned by query is a global property of ConfigBean. 4) The problem arises only in Jetty and not in Tomcat. In oder to reach 1) I've added a property (nickName) in LoginAction which is rendered by home.xhtml. Seam then tries to create the ConfigBean I've put in example. In order to reach 2) I've created a new entity Phone. Hotel has a one-to-many relationship with Phone entities. -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBCACHE-388) Provide modified data in callbacks

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-388?page=all ] Manik Surtani closed JBCACHE-388. --------------------------------- Resolution: Done Done, see the new CacheListener interfaces. > Provide modified data in callbacks > ---------------------------------- > > Key: JBCACHE-388 > URL: http://jira.jboss.com/jira/browse/JBCACHE-388 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2 > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.0.0 > > > All callbacks should ship the data they refer to, e.g. put() should have a list of modified / inserted attributes etc. > We should define the data that needs to e provided for each callback. > This should go into ExtendedTreeCacheListener (which will be merged with TreeCacheListener in 2.x). -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-92) Eviction of entire subtrees

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-92?page=all ] Manik Surtani closed JBCACHE-92. -------------------------------- Resolution: Done > Eviction of entire subtrees > --------------------------- > > Key: JBCACHE-92 > URL: http://jira.jboss.com/jira/browse/JBCACHE-92 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 1.2 > Reporter: Bela Ban > Assigned To: Daniel Huang > Fix For: 2.0.0 > > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAOP-255) Instanceof expressions and methods overriding with a different return type

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-255?page=comments#action_12345503 ] Kabir Khan commented on JBAOP-255: ---------------------------------- class Super { Object getFoo(){} } class POJO extends Super { String getFoo(){} } becomes class Super { Object getFoo(){} } class POJO extends Super { String getFoo(){} volatile Object getFoo(){} } The extra volatile method is a "bridge method". (ACC_VOLATILE and ACC_BRIDGE are both 0x00000040). http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.ht... > Instanceof expressions and methods overriding with a different return type > -------------------------------------------------------------------------- > > Key: JBAOP-255 > URL: http://jira.jboss.com/jira/browse/JBAOP-255 > Project: JBoss AOP > Issue Type: Bug > Affects Versions: 1.5.0.GA > Reporter: Kabir Khan > Fix For: 2.0.0.alpha3 > > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-663) Local interface should be preferred over remote when injected via @EJB

by Petr Matejka (JIRA)

Local interface should be preferred over remote when injected via @EJB ---------------------------------------------------------------------- Key: EJBTHREE-663 URL: http://jira.jboss.com/jira/browse/EJBTHREE-663 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC8 - FD Reporter: Petr Matejka Having a session-bean with interface annotated with both @Local and @Remote annotations and injected into another session-bean via @EJB, the injected proxy should be local proxy and not remote proxy. I think changing ProxyFactoryHelper.getJNDIName should do the thing. -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Resolved: (JBAOP-89) MC aspect deployer

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-89?page=all ] Kabir Khan resolved JBAOP-89. ----------------------------- Resolution: Duplicate Issue Assignee: Kabir Khan (was: Bill Burke) http://jira.jboss.com/jira/browse/JBAOP-292 > MC aspect deployer > ------------------ > > Key: JBAOP-89 > URL: http://jira.jboss.com/jira/browse/JBAOP-89 > Project: JBoss AOP > Issue Type: Task > Components: Aspect Library > Reporter: Adrian Brock > Assigned To: Kabir Khan > > Need to write an aspect deployer that uses the new deployer framework in system2 > i.e. it parses jboss-aop.xml and creates BeanMetaData configuration for the MicroContainer > to configure the AspectManager when dependencies are satisfied. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-767) Fail more silently when setting node versions

by Owen Taylor (JIRA)

Fail more silently when setting node versions --------------------------------------------- Key: JBCACHE-767 URL: http://jira.jboss.com/jira/browse/JBCACHE-767 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Owen Taylor Assigned To: Manik Surtani Priority: Minor Attachments: jbosscache-fail-more-silently-20060912.patch Hibernate's OptimisticTreeCache.writeUpdate does: Option option = new Option(); option.setFailSilently( true ); option.setDataVersion( NonLockingDataVersion.INSTANCE ); cache.remove( new Fqn( regionFqn, key ), "ITEM", option ); Which you would expect would remove the item if it exists, while setting the data version, and silently do nothing otherwise. But it ends up, logging at level INFO: 12:55:38,360 INFO [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request java.lang.NullPointerException at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530) at org.jboss.cache.TreeCache.remove(TreeCache.java:3742) at org.jboss.cache.TreeCache.remove(TreeCache.java:3297) at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76) There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious problem. What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current NullPointerException. -- 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, 2 months

2
9
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006