August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-676) PojoCache map implementation needs to handle the case where key is PojoCacheable

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-676?page=all ] Ben Wang updated JBCACHE-676: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > PojoCache map implementation needs to handle the case where key is PojoCacheable > -------------------------------------------------------------------------------- > > Key: JBCACHE-676 > URL: http://jira.jboss.com/jira/browse/JBCACHE-676 > 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 > > > This is illustrated in org.jboss.cache.pojo.RecrusiveRefTest where we have map.put(valueId, valueObject) where both are PojoCacheable and valueId also embeded in valueObject. Therefore, if we treat valueId just as a Serializable, replication will cause the object reference split in valueObject (becuase in valueObject, valueId is treated by PojoCache). -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-69) Create an analysis comparing HttpSession replication in JBoss to BEA's implementation

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-69?page=all ] Brian Stansberry updated JBCLUSTER-69: -------------------------------------- Fix Version/s: Q4Y6 (was: Q3Y6) > Create an analysis comparing HttpSession replication in JBoss to BEA's implementation > ------------------------------------------------------------------------------------- > > Key: JBCLUSTER-69 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-69 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: Q4Y6 > > > We need to compare the features/capabilities of our session replication approach to BEA's. The results of the analysis should be a driver for the session replication roadmap. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-245) Validate PojoCache with passivation

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-245?page=all ] Ben Wang resolved JBCACHE-245. ------------------------------ Resolution: Done > Validate PojoCache with passivation > ----------------------------------- > > Key: JBCACHE-245 > URL: http://jira.jboss.com/jira/browse/JBCACHE-245 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: POJOCache > Reporter: Ben Wang > Assigned To: Daniel Huang > Fix For: 2.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > We will need to test out the new passivation together with eviction under JBossCacheAop -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-245) Validate PojoCache with passivation

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-245?page=all ] Ben Wang updated JBCACHE-245: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > Validate PojoCache with passivation > ----------------------------------- > > Key: JBCACHE-245 > URL: http://jira.jboss.com/jira/browse/JBCACHE-245 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: POJOCache > Reporter: Ben Wang > Assigned To: Daniel Huang > Fix For: 2.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > We will need to test out the new passivation together with eviction under JBossCacheAop -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-561) Create a separate META-INF sub-directory for PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-561?page=all ] Ben Wang updated JBCACHE-561: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > Create a separate META-INF sub-directory for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-561 > URL: http://jira.jboss.com/jira/browse/JBCACHE-561 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Minor > Fix For: 2.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Separate the PojoCache configuration from regular TreeCache so that user don't get confused. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-88) Cluster configuration wizard

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-88?page=all ] Brian Stansberry updated JBCLUSTER-88: -------------------------------------- Fix Version/s: Q1Y7 (was: Q3Y6) > Cluster configuration wizard > ---------------------------- > > Key: JBCLUSTER-88 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-88 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > > Maybe in collaboration with JBoss Network (or maybe they are working on it). > - Tool to configure clustering, generates e.g. cluster-service.xml file > - First pick what needs to be clustered, e.g. base clustering (HA-JNDI etc), HTTP session replication, clustered EJB3 etc > - Then, for each cluster, configure: > - what transport (default) > - what bind address (tool should probe for NIC and display them in a list) > - for TCP: list of nodes > - If TCP: no FRAG, no UNICAST > - If UDP: what mcast address, TTL, port > - Wizard should run sanity tests after config, e.g. are clusters cleanly separated ? > - Wizard should provide defaults, so pressing Enter on every decision leads to the default clustering config > - Wizard should also be able to parse existing config, and reconfig 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-687) PojoCache to use aop 2.0 to bind interceptor dynamically

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-687?page=all ] Ben Wang updated JBCACHE-687: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > PojoCache to use aop 2.0 to bind interceptor dynamically > -------------------------------------------------------- > > Key: JBCACHE-687 > URL: http://jira.jboss.com/jira/browse/JBCACHE-687 > 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 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently in 2.0, I am introducing new field level interceptos such as SubjectInterceptor to emit the field events. However, make "introduction" to a POJO with a Subject interface also has the side effect of the interceptor will bind to that method jointpoint as well. This is not desirable. > Workaround is to check for MehtodInvocation is each field level interceptor or in AOP2.0, we can bind specifically to the Pointcut programmtically as discussed in the forum post. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-23) Consolidate clustering configuration frontend for state replication

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-23?page=all ] Brian Stansberry updated JBCLUSTER-23: -------------------------------------- Fix Version/s: Q4Y6 (was: Q3Y6) > Consolidate clustering configuration frontend for state replication > ------------------------------------------------------------------- > > Key: JBCLUSTER-23 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-23 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Critical > Fix For: Q4Y6 > > Original Estimate: 8 weeks > Remaining Estimate: 8 weeks > > Currently we have cluster-service.xml, tc5-cluster-serviec.xml, and other tree-cache.xml to run on tops of JGroups for various replication and clustering purpose. In ejb3, we will run into this problem of SFSB and entity bean using JBossCache. > There comes a need to consolidate all these configuration so to a end user it is consistent. > Solution may be to put in another integration layer to hide JBossCache configuration somewhat. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-217) unplugging of network cable makes jgroups behave weirdly

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-217?page=comments#action_12341169 ] Bela Ban commented on JGRP-217: ------------------------------- Okay, found the problem: ViewSyncHeader (in VIEW_SYNC) always expects a View, and when we get a MergeView, then the stream will be corrupted because we read the wrong data (View instead of MergeView). Will change it in VIEW_SYNC.ViewSyncHeader > unplugging of network cable makes jgroups behave weirdly > -------------------------------------------------------- > > Key: JGRP-217 > URL: http://jira.jboss.com/jira/browse/JGRP-217 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8, 2.2.9, 2.3 > Reporter: Manoranjan Sahu > Assigned To: Bela Ban > Fix For: 2.4 > > Attachments: logs.jar, mping.xml, pull-tcp.xml, pulltheplug.xml > > > Hi, > I am using jgroups 2.2.9 for communication in my cluster. > I was checking the behaviour of jgroups to network fluctuation. > for that I manually unplug the network cable and plug it back after some time. > But jgroups keeps sending suspected messages and never bring that into the cluster. > I have two machines in my cluster A(10.200.1.92) & B(10.200.1.74). > I unplug the cable in machine B. and plug it back . but B never joined the cluster. > Please find the attachment for the log files from both the machines. > I am using TCP based communication. I set up my protocol stack using . MPING,MERGE2,FD,VERIFY_SUSPECT,pbcast.NAKACK,pbcast.STABLE,VIEW_SYNC,pbcast.GMS. > The following are the confuguration in both the machines. > configuration setting in Machine-A > notificationbus.properties: > TCP(bind_addr=boca;recv_buf_size=200000;send_buf_size=100000;loopback=true; > start_port=7880): > MPING(timeout=4000;bind_to_all_interfaces=true;mcast_addr=228.8.8.8;mcast_port=7500; > ip_ttl=8;num_initial_members=4;num_ping_requests=1): > MERGE2(max_interval=10000;min_interval=5000): > FD(timeout=2000;max_tries=3): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(max_xmit_size=60000;gc_lag=50; > retransmit_timeout=100,200,300,600,1200,2400,4800): > pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;down_thread=false; > up_thread=false;max_bytes=0): > VIEW_SYNC(avg_send_interval=60000;down_thread=false;up_thread=false): > pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true) > ------------------------------- > configuration setting in Machine-B > notificationbus.properties: > TCP(bind_addr=rizal;recv_buf_size=200000;send_buf_size=100000; > loopback=true;start_port=7880): > MPING(timeout=4000;bind_to_all_interfaces=true;mcast_addr=228.8.8.8; > mcast_port=7500;ip_ttl=8;num_initial_members=4;num_ping_requests=1): > MERGE2(max_interval=10000;min_interval=5000):FD(timeout=2000;max_tries=3): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(max_xmit_size=60000;gc_lag=50; > retransmit_timeout=100,200,300,600,1200,2400,4800): > pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;down_thread=false; > up_thread=false;max_bytes=0): > VIEW_SYNC(avg_send_interval=60000;down_thread=false;up_thread=false): > pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true) > ---------------- -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBESB-15) Basic transformation integration using Smooks

by Tom Fennelly (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-15?page=all ] Tom Fennelly updated JBESB-15: ------------------------------ Affects Version/s: 4.0 (was: 1.0 Alpha 1) > Basic transformation integration using Smooks > --------------------------------------------- > > Key: JBESB-15 > URL: http://jira.jboss.com/jira/browse/JBESB-15 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: ESB Core > Affects Versions: 4.0 > Reporter: Mark Little > Assigned To: Tom Fennelly > Fix For: 4.0 > > > Develop an abstract transformation service interface that does not tie us to any specific implementation. > Look at smooks (http://milyn.org/Smooks) as an initial implementation. -- 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

19 years, 11 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 August 2006