[JBoss-dev] [JBoss JIRA] Created: (JGRP-54) Remove flow control from UNICAST (provided by FC)
Remove flow control from UNICAST (provided by FC) - Key: JGRP-54 URL: http://jira.jboss.com/jira/browse/JGRP-54 Project: JGroups Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 Flow control is provided by FC already, we don't need it in UNICAST -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JGRP-16) GMS.getDigest() needs to be run in a separate thread
[ http://jira.jboss.com/jira/browse/JGRP-16?page=history ] Bela Ban closed JGRP-16: Resolution: Done analyzed it; not needed > GMS.getDigest() needs to be run in a separate thread > > > Key: JGRP-16 > URL: http://jira.jboss.com/jira/browse/JGRP-16 > Project: JGroups > Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > > Original Estimate: 1 day > Remaining: 1 day > > Not a bug, but results in slight performance imporvement -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-4) UDP.bundling too slow
[ http://jira.jboss.com/jira/browse/JGRP-4?page=history ] Bela Ban resolved JGRP-4: - Resolution: Done Rewrote impl. General problem is that bundling usually exceeds ethernet MTU of 1500 bytes, so is counter-productive. See JGroups wiki for details (jboss.com) > UDP.bundling too slow > - > > Key: JGRP-4 > URL: http://jira.jboss.com/jira/browse/JGRP-4 > Project: JGroups > Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > Original Estimate: 3 days > Remaining: 3 days > > Possible problem with nulling of msg addresses -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JGRP-3) Timer in UDP.bundling is implemented incorrectly
[ http://jira.jboss.com/jira/browse/JGRP-3?page=history ] Bela Ban closed JGRP-3: --- Resolution: Done rewrote bundling - uses its own thread now, no needfor timer > Timer in UDP.bundling is implemented incorrectly > > > Key: JGRP-3 > URL: http://jira.jboss.com/jira/browse/JGRP-3 > Project: JGroups > Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > > Original Estimate: 1 day > Remaining: 1 day > > We can have multiple timers running at the same time ! -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-53) NakReceiverWindow: replace updateHighestSeen() with more efficient function
[ http://jira.jboss.com/jira/browse/JGRP-53?page=history ] Bela Ban resolved JGRP-53: -- Resolution: Done done > NakReceiverWindow: replace updateHighestSeen() with more efficient function > --- > > Key: JGRP-53 > URL: http://jira.jboss.com/jira/browse/JGRP-53 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > > Currently, updateHighestSeen() is linear (iterating over entire list of > messages), can be more efficient -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-53) NakReceiverWindow: replace updateHighestSeen() with more efficient function
[ http://jira.jboss.com/jira/browse/JGRP-53?page=history ] Bela Ban updated JGRP-53: - Summary: NakReceiverWindow: replace updateHighestSeen() with more efficient function (was: NakReceiverWindow: replace updateLowestSeen() with more efficient function) Description: Currently, updateHighestSeen() is linear (iterating over entire list of messages), can be more efficient (was: Currently, updateLowestSeen() and updateHighestSeen() are linear (iterating over entire list of messages), can be more efficient) > NakReceiverWindow: replace updateHighestSeen() with more efficient function > --- > > Key: JGRP-53 > URL: http://jira.jboss.com/jira/browse/JGRP-53 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > > Currently, updateHighestSeen() is linear (iterating over entire list of > messages), can be more efficient -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-52) Replace RWLock with util.concurrent
[ http://jira.jboss.com/jira/browse/JGRP-52?page=history ] Bela Ban resolved JGRP-52: -- Resolution: Done > Replace RWLock with util.concurrent > --- > > Key: JGRP-52 > URL: http://jira.jboss.com/jira/browse/JGRP-52 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-53) NakReceiverWindow: replace updateLowestSeen() with more efficient function
NakReceiverWindow: replace updateLowestSeen() with more efficient function -- Key: JGRP-53 URL: http://jira.jboss.com/jira/browse/JGRP-53 Project: JGroups Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 Currently, updateLowestSeen() and updateHighestSeen() are linear (iterating over entire list of messages), can be more efficient -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-52) Replace RWLock with util.concurrent
Replace RWLock with util.concurrent --- Key: JGRP-52 URL: http://jira.jboss.com/jira/browse/JGRP-52 Project: JGroups Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-19) MERGE2 slows down traffic
[ http://jira.jboss.com/jira/browse/JGRP-19?page=history ] Bela Ban resolved JGRP-19: -- Resolution: Done Presence of MERGE2 doesn't make a diff in CVS head anymore > MERGE2 slows down traffic > - > > Key: JGRP-19 > URL: http://jira.jboss.com/jira/browse/JGRP-19 > Project: JGroups > Type: Bug > Environment: JGroups 2.2.8 (CVS Jan 6 2005) > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > Attachments: Tester.java > > Original Estimate: 2 days > Remaining: 2 days > > Look into why max and avg values for a stack with MERGE2 are slower than for > a stack without MERGE2 > > > num_initial_members="3"/> > > > > > down_thread="false" max_bytes="0" up_thread="false"/> > join_retry_timeout="2000" shun="true"/> > > > Before your Fix: Version 2.2.8 > > Average receiving time(in milliseconds): 1106 > Max reciving time(in milliseconds: 3266 > Min reciving time(in milliseconds: 0 > > > After your Fix: Latest from Head > > Average receiving time(in milliseconds): 342 > Max reciving time(in milliseconds: 1250 > Min reciving time(in milliseconds: 0 > > > > > > num_initial_members="3"/> > > > > down_thread="false" max_bytes="0" up_thread="false"/> > join_retry_timeout="2000" shun="true"/> > > > > > Before your Fix: Version 2.2.8 > > Average receiving time(in milliseconds): 36 > Max reciving time(in milliseconds: 219 > Min reciving time(in milliseconds: 0 > > > After your Fix: Latest from Head > Average receiving time(in milliseconds): 29 > Max reciving time(in milliseconds: 109 > Min reciving time(in milliseconds: 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=history ] Bela Ban updated JGRP-33: - Priority: Major (was: Critical) downgraded to major; probably due to incorrect use of JGroups > JGroups throws OutOfMemoryError after running for a few hours > - > > Key: JGRP-33 > URL: http://jira.jboss.com/jira/browse/JGRP-33 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 & SUN JDK 1.5.0 on Windows & Unix platforms > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: JGroupsMemTest.java, PublishThread2.java, > fc-fast-udp-tcpping.xml, fc-fast-udp.xml, runj10.sh > > > I ran 10 instances of a simple program with 3 threads. The max memory is kept > as the JVM default (64M). The 10 programs join the same JGroup and the > threads in the programs keep publishing a small hashmap at 5 second intervals. > The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) > slowly increases over a period of 4-5 hours and reaches the default max limit > (64M) when it starts throwing OutOfMemory errors on all instances. > I have run the program on unix and windows machines with 1G RAM. > Not able to make much from an HProf output of one of the instances. > This seems to be the cause for the JBossCache bug > "http://jira.jboss.com/jira/browse/JBCACHE-31"; too. > I have tried out a UDP/PING and a UDP/TCPPING combination and this problem > occurs in both cases. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-28) Remove sendDummyPacket() in UDP
[ http://jira.jboss.com/jira/browse/JGRP-28?page=history ] Bela Ban resolved JGRP-28: -- Resolution: Done Removed sendDummyPacket() > Remove sendDummyPacket() in UDP > --- > > Key: JGRP-28 > URL: http://jira.jboss.com/jira/browse/JGRP-28 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > > Original Estimate: 2 hours > Remaining: 2 hours > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-28) Remove sendDummyPacket() in UDP
[ http://jira.jboss.com/jira/browse/JGRP-28?page=comments#action_12316770 ] Bela Ban commented on JGRP-28: -- Was caused by sendDummyPacket() in UDP - will remove it shortly > Remove sendDummyPacket() in UDP > --- > > Key: JGRP-28 > URL: http://jira.jboss.com/jira/browse/JGRP-28 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > > Original Estimate: 2 hours > Remaining: 2 hours > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-22) Enhance the ENCRYPT or the ENCRYPT1_4 protocol
[ http://jira.jboss.com/jira/browse/JGRP-22?page=history ] Bela Ban resolved JGRP-22: -- Resolution: Done Fix Version: 2.2.8 (was: 2.2.9) > Enhance the ENCRYPT or the ENCRYPT1_4 protocol > --- > > Key: JGRP-22 > URL: http://jira.jboss.com/jira/browse/JGRP-22 > Project: JGroups > Type: Feature Request > Versions: 2.2.8 > Reporter: Roland R?z > Assignee: Bela Ban > Fix For: 2.2.8 > > > The ENCRYPT and the ENCRYPT1_4 protocol have both some weaknesses and missing > features. There is no strong protection against replay attacks, everybody can > join when using an asymmetric algorithm and messages encrypted with a wrong > key are not discarded. > The difference between the ENCRYPT1_4 and the ENCRYPT protocol is that > ENCRYPT1_4 provides no support for a configured symmetric key (ENCRYPT1_4 > generates and distributes a symmetric key). ENCRYPT provides a feature for a > symmetric key configured in a keystore. In this case the asymmetric key > generation is not used. The symmetric and asymmetric features cannot be > combined. > The asymmetric and symmetric part of the ENCRYPT protocol could be separated > in two protocols and some features could be enhanced. > The ultimate solution could look like that: > The lowest (e.g. CRYPTO_SYM) would be responsible for encryption/decryption > and could be used in any layer below the symmetric cryptography (e.g. > CRYPTO_KEY_DIST) protocol. The key for CRYPTO_SYM comes either from a file > (e.g. as keystore or just as binary stuff protected with file system rights) > or from a file AND from CRYPTO_SYM. In the second mode (CRYPTO_SYM + > CRYPTO_KEY_DIST) CRYPTO_SYM needs to encrypt/decrypt the messages from > CRYPTO_KEY_DIST with the simple file or keystore based key or does not need > to be encrypted (to solve bootstrap, synchronization). The type of the > message (is from CRYPTO_KEY_DIST or not) has to be sent along the wire. > CRYPTO_KEY_DIST must be above the "reliability" layers and the master creates > for each change in the view a new key. This key is sent down to the > CRYPTO_SYM layer where it is combined with the symmetric key. CRYPTO_KEY_DIST > should verify a new member with a challenge response procedure (e.g. based on > the same symmetric key as CRYPTO_SYM) > A nice feature of the CRYPTO_SYM would be to hash the messages and encrypt > the hash along with the message so that the message can be verified. > Currently the layers above ENCRYPT have to handle and discard corrupt > messages. > CRYPTO_SYM could be run without CRYPTO_KEY_DIST but the usage of both > together would protect JGroups from replay attacks. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-31) Problem with MERGE2 when not using multicast
[ http://jira.jboss.com/jira/browse/JGRP-31?page=history ] Bela Ban resolved JGRP-31: -- Resolution: Done I added the merge_leader flag to GMS. Another possibility to solve this is to use the TCP:MPING combination > Problem with MERGE2 when not using multicast > > > Key: JGRP-31 > URL: http://jira.jboss.com/jira/browse/JGRP-31 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN Java 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > > > Hi, > There is one case in which MERGE2 will fail while using TCPPING/UDP(without > mcast): > > The initial_hosts property is "abc.com[7800];xyz.com[7801]". > These 2 machines are permanent group members (if they are up, they will be > members of the group). > Now there are numerous other programs on different machines that may > dynamically join and leave the group. These members are not known before hand > and cannot be specified in the initial_hosts property. > The members on abc.com and xyz.com are started and they join the same group. > Now another member from "mnop.com" starts and joins the group. The > co-ordinator will be abc.com > A network problem occurs and mnop.com is separated from abc.com and xyz.com > mnop.com forms its own single-member group with itself as the co-ordinator. > Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com > periodically checks on the initial_hosts list to see if they are up. It now > finds that abc.com is reachable and decides that abc.com is the leader (by > lexical sorting) and will take care of the merging. So it does not go ahead > with the merge. > On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check > if they can find members on the initial_hosts with a different co-ordinator. > Both of them never consider mnop.com as it is not in the initial_hosts list > So mnop.com will never be merged with the group. > > Even the new MERGE3 & MERGEFAST protocols don't seem to help here. I checked > them out and found the following: > MERGEFAST works only if multicast is used, which is not my case. > MERGE3 just sends "I am co-ordinator" messages to a null destination. So in > the case where multicast is enabled, it goes to all possible members. But in > my case, with multicast disabled, the message will only be unicast to each > member of the current group. So in the above example, the "I am co-ordinator" > messages will never go to mnop.com after the network problem. > So even MERGE3 does not work in this 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JGRP-45) JVM Crashes when starting three groups at the same time
[ http://jira.jboss.com/jira/browse/JGRP-45?page=history ] Bela Ban closed JGRP-45: Resolution: Done This has nothing to do with JGroups; the log clearly shows that it was the JMS invocation layer which crashed. Although I doubt that code can crash the VM, I think this is a VM bug > JVM Crashes when starting three groups at the same time > --- > > Key: JGRP-45 > URL: http://jira.jboss.com/jira/browse/JGRP-45 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: Linux RedHat 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST > 2004 i686 i686 i386 GNU/Linux (our dev02 box) > Reporter: Clebert Suconic > Assignee: Bela Ban > Priority: Minor > Fix For: 2.2.8 > Attachments: console3.out.gz > > > When starting three clusters at the same time, a JVM crashed inside the > socket JNI function. > I've added the log file for the crashed instance. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
[ http://jira.jboss.com/jira/browse/JGRP-40?page=history ] Bela Ban resolved JGRP-40: -- Resolution: Done Please re-open the case if you find the problem still exists > Connections remain open even after the channel port changes, while using TCP > > > Key: JGRP-40 > URL: http://jira.jboss.com/jira/browse/JGRP-40 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: ShunTest.java, default.xml, tcp.xml > > > I am using TCP/TCPPING as the base of the stack. Sometimes one of the > members of the group gets shunned. That member then disconnects from the > group and re-connects. This time, it gets assigned a different TCP port. > But a netstat for ESTABLISHED connections shows the connections of the old > and the new port still active. > Shouldn't the connections for the old port have been closed? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
[ http://jira.jboss.com/jira/browse/JGRP-40?page=history ] Bela Ban updated JGRP-40: - Attachment: tcp.xml > Connections remain open even after the channel port changes, while using TCP > > > Key: JGRP-40 > URL: http://jira.jboss.com/jira/browse/JGRP-40 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: ShunTest.java, default.xml, tcp.xml > > > I am using TCP/TCPPING as the base of the stack. Sometimes one of the > members of the group gets shunned. That member then disconnects from the > group and re-connects. This time, it gets assigned a different TCP port. > But a netstat for ESTABLISHED connections shows the connections of the old > and the new port still active. > Shouldn't the connections for the old port have been closed? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
[ http://jira.jboss.com/jira/browse/JGRP-40?page=history ] Bela Ban updated JGRP-40: - Attachment: default.xml > Connections remain open even after the channel port changes, while using TCP > > > Key: JGRP-40 > URL: http://jira.jboss.com/jira/browse/JGRP-40 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: ShunTest.java, default.xml, tcp.xml > > > I am using TCP/TCPPING as the base of the stack. Sometimes one of the > members of the group gets shunned. That member then disconnects from the > group and re-connects. This time, it gets assigned a different TCP port. > But a netstat for ESTABLISHED connections shows the connections of the old > and the new port still active. > Shouldn't the connections for the old port have been closed? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
[ http://jira.jboss.com/jira/browse/JGRP-40?page=comments#action_12316766 ] Bela Ban commented on JGRP-40: -- Ran the attached example with both default.xml and tcp.xml (attached as well). Works okay with 2.2.8 CVS head > Connections remain open even after the channel port changes, while using TCP > > > Key: JGRP-40 > URL: http://jira.jboss.com/jira/browse/JGRP-40 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: ShunTest.java > > > I am using TCP/TCPPING as the base of the stack. Sometimes one of the > members of the group gets shunned. That member then disconnects from the > group and re-connects. This time, it gets assigned a different TCP port. > But a netstat for ESTABLISHED connections shows the connections of the old > and the new port still active. > Shouldn't the connections for the old port have been closed? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
[ http://jira.jboss.com/jira/browse/JGRP-40?page=history ] Bela Ban updated JGRP-40: - Attachment: ShunTest.java Example > Connections remain open even after the channel port changes, while using TCP > > > Key: JGRP-40 > URL: http://jira.jboss.com/jira/browse/JGRP-40 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 > Reporter: B.S.Navin > Assignee: Bela Ban > Fix For: 2.2.8 > Attachments: ShunTest.java > > > I am using TCP/TCPPING as the base of the stack. Sometimes one of the > members of the group gets shunned. That member then disconnects from the > group and re-connects. This time, it gets assigned a different TCP port. > But a netstat for ESTABLISHED connections shows the connections of the old > and the new port still active. > Shouldn't the connections for the old port have been closed? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-51) Update manifest and Version.java with version number
Update manifest and Version.java with version number Key: JGRP-51 URL: http://jira.jboss.com/jira/browse/JGRP-51 Project: JGroups Type: Sub-task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-48) Add version number of manifest
[ http://jira.jboss.com/jira/browse/JGRP-48?page=history ] Bela Ban resolved JGRP-48: -- Resolution: Done > Add version number of manifest > -- > > Key: JGRP-48 > URL: http://jira.jboss.com/jira/browse/JGRP-48 > Project: JGroups > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-39) A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations
[ http://jira.jboss.com/jira/browse/JGRP-39?page=history ] Bela Ban resolved JGRP-39: -- Resolution: Done Works with 2.2.8 (CVS head) > A TCP stack does not correctly detect failure (pulled cable) for certain > TCPPING configurations > --- > > Key: JGRP-39 > URL: http://jira.jboss.com/jira/browse/JGRP-39 > Project: JGroups > Type: Bug > Versions: 2.2.9 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > Physical hosts "A" (192.168.1.1, coordinator) and "B" (192.168.1.2) run > JGroups processes configured with TCP/TCPPING stacks. > "A" stack configuration: > TCP(bind_addr=192.168.1.1;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.2[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=1): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > "B" stack configuration: > TCP(bind_addr=192.168.1.2;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.1[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=1): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > If I pull the cable under B, the B stack immediately and correctly > indentifies A as suspect and installs a new view containing itself only. > However, A does not recognizes B as suspect and undeterministically spews out > various info and warning messages. The view (A, B) stays incorrectly "valid" > for a long time; sometimes gets replaced by (A), sometimes not. > I tracked down the cause of the problem down to the A TCPPING configuration > and TCP queue . If A's TCPPING is configured with a port_range=1, the > problem goes away and the new view immediately installs into the A stack. It > seems that if there are messages in the TCP queue except the SUSPECT message > generated by FD, they mess up things and the SUSPECT message gets stuck in > the queue, with undeterministic results. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-126) CacheLoader doesn't load children after loading an attribute
[ http://jira.jboss.com/jira/browse/JBCACHE-126?page=history ] Bela Ban resolved JBCACHE-126: -- Resolution: Done Added children_loaded to Node, changed CacheLoaderInterceptor > CacheLoader doesn't load children after loading an attribute > > > Key: JBCACHE-126 > URL: http://jira.jboss.com/jira/browse/JBCACHE-126 > Project: JBoss Cache > Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-126) CacheLoader doesn't load children after loading an attribute
CacheLoader doesn't load children after loading an attribute Key: JBCACHE-126 URL: http://jira.jboss.com/jira/browse/JBCACHE-126 Project: JBoss Cache Type: Bug Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.3 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-50) Release 2.2.8 final
Release 2.2.8 final --- Key: JGRP-50 URL: http://jira.jboss.com/jira/browse/JGRP-50 Project: JGroups Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-125) Release 1.2.3 final
Release 1.2.3 final --- Key: JBCACHE-125 URL: http://jira.jboss.com/jira/browse/JBCACHE-125 Project: JBoss Cache Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.3 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-124) Concurrent access problem in Node
[ http://jira.jboss.com/jira/browse/JBCACHE-124?page=history ] Bela Ban resolved JBCACHE-124: -- Resolution: Done Made it a ConcurrentReaderHashMap > Concurrent access problem in Node > - > > Key: JBCACHE-124 > URL: http://jira.jboss.com/jira/browse/JBCACHE-124 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > > Problem: Node.data is a HashMap, not a ConcurrentReaderHashMap -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-124) Concurrent access problem in Node
Concurrent access problem in Node - Key: JBCACHE-124 URL: http://jira.jboss.com/jira/browse/JBCACHE-124 Project: JBoss Cache Type: Bug Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.3 Problem: Node.data is a HashMap, not a ConcurrentReaderHashMap -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-51) Create standalone CVS version of JBossCache
[ http://jira.jboss.com/jira/browse/JBCACHE-51?page=history ] Bela Ban resolved JBCACHE-51: - Resolution: Done New module is "JBossCache", check out: cvs co JBossCache > Create standalone CVS version of JBossCache > --- > > Key: JBCACHE-51 > URL: http://jira.jboss.com/jira/browse/JBCACHE-51 > Project: JBoss Cache > Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > Original Estimate: 1 week > Remaining: 1 week > > Goals: > - Standalone CVS version of JBossCache --> extract code into a different > location in the src > tree > - Create the integration code inside the JBossAS src tree -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBCACHE-123) Get rid of JBoss-dependent libs
[ http://jira.jboss.com/jira/browse/JBCACHE-123?page=history ] Bela Ban closed JBCACHE-123: Resolution: Done This task will be done later (in 1.3, when we convert to interfaces) > Get rid of JBoss-dependent libs > --- > > Key: JBCACHE-123 > URL: http://jira.jboss.com/jira/browse/JBCACHE-123 > Project: JBoss Cache > Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-122) Convert JBoss Logger to commons-logging
[ http://jira.jboss.com/jira/browse/JBCACHE-122?page=history ] Bela Ban resolved JBCACHE-122: -- Resolution: Done > Convert JBoss Logger to commons-logging > --- > > Key: JBCACHE-122 > URL: http://jira.jboss.com/jira/browse/JBCACHE-122 > Project: JBoss Cache > Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > > get rid of jboss-common -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-70) Make JBossCache an XAResource
[ http://jira.jboss.com/jira/browse/JBCACHE-70?page=comments#action_12316637 ] Bela Ban commented on JBCACHE-70: - Interesting read: http://www.jboss.org/wiki/Wiki.jsp?page=TransactionRecovery > Make JBossCache an XAResource > - > > Key: JBCACHE-70 > URL: http://jira.jboss.com/jira/browse/JBCACHE-70 > Project: JBoss Cache > Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-49) org.jgroups.protocols.UDP.stopThreads() doesn't stop outgoing_packet_handler
[ http://jira.jboss.com/jira/browse/JGRP-49?page=history ] Bela Ban resolved JGRP-49: -- Resolution: Done Fixed. Although this didn't cause multiple outgoing packet threads to be created b/c OutgoingPacketHandler.start() would not start a new thread if the old thread was still running. However, the current solution is cleaner. Thanks for detecting this ! > org.jgroups.protocols.UDP.stopThreads() doesn't stop outgoing_packet_handler > > > Key: JGRP-49 > URL: http://jira.jboss.com/jira/browse/JGRP-49 > Project: JGroups > Type: Bug > Environment: version 2.2.7 all platforms > Reporter: Steve Nicolai > Assignee: Bela Ban > Fix For: 2.2.8 > > > When a channel is disconnected, stop() is called for all items in the > protocol stack. UDP.stop() calls stopThreads() which does not stop the > outgoing_packet_handler. > This causes multiple of these threads to be created if a channel is started > and stopped in an application. > Proposed fix, at the bottom of org.jgroups.protocols.UDP.stopThreads() add > the following: > // 4. if (outgoing_packet_handler != null) > outgoing_packet_handler.stop(); -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-49) org.jgroups.protocols.UDP.stopThreads() doesn't stop outgoing_packet_handler
[ http://jira.jboss.com/jira/browse/JGRP-49?page=history ] Bela Ban updated JGRP-49: - Fix Version: 2.2.8 > org.jgroups.protocols.UDP.stopThreads() doesn't stop outgoing_packet_handler > > > Key: JGRP-49 > URL: http://jira.jboss.com/jira/browse/JGRP-49 > Project: JGroups > Type: Bug > Environment: version 2.2.7 all platforms > Reporter: Steve Nicolai > Assignee: Bela Ban > Fix For: 2.2.8 > > > When a channel is disconnected, stop() is called for all items in the > protocol stack. UDP.stop() calls stopThreads() which does not stop the > outgoing_packet_handler. > This causes multiple of these threads to be created if a channel is started > and stopped in an application. > Proposed fix, at the bottom of org.jgroups.protocols.UDP.stopThreads() add > the following: > // 4. if (outgoing_packet_handler != null) > outgoing_packet_handler.stop(); -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316533 ] Bela Ban commented on JBCACHE-98: - Yes, but I'm talking about 1.2.2 not 1.2.1 > Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases > -- > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Bela Ban > Fix For: 1.2.2 > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-48) Add version number of manifest
Add version number of manifest -- Key: JGRP-48 URL: http://jira.jboss.com/jira/browse/JGRP-48 Project: JGroups Type: Task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-122) Convert JBoss Logger to commons-logging
[ http://jira.jboss.com/jira/browse/JBCACHE-122?page=history ] Bela Ban updated JBCACHE-122: - Fix Version: 1.2.3 > Convert JBoss Logger to commons-logging > --- > > Key: JBCACHE-122 > URL: http://jira.jboss.com/jira/browse/JBCACHE-122 > Project: JBoss Cache > Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > > get rid of jboss-common -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-36) TCP:PING, TCP transport combined with multicast discovery
[ http://jira.jboss.com/jira/browse/JGRP-36?page=history ] Bela Ban updated JGRP-36: - Fix Version: 2.2.8 (was: 2.2.9) > TCP:PING, TCP transport combined with multicast discovery > - > > Key: JGRP-36 > URL: http://jira.jboss.com/jira/browse/JGRP-36 > Project: JGroups > Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > > Use IP multicast for discovery/merging, but TCP for transport -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-4) UDP.bundling too slow
[ http://jira.jboss.com/jira/browse/JGRP-4?page=history ] Bela Ban updated JGRP-4: Summary: UDP.bundling too slow (was: UDB.bundling too slow) Environment: > UDP.bundling too slow > - > > Key: JGRP-4 > URL: http://jira.jboss.com/jira/browse/JGRP-4 > Project: JGroups > Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > Original Estimate: 3 days > Remaining: 3 days > > Possible problem with nulling of msg addresses -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-42) White paper on AOP (for session repl)
[ http://jira.jboss.com/jira/browse/JBCACHE-42?page=history ] Bela Ban updated JBCACHE-42: Fix Version: 1.2.4 (was: 1.2.3) > White paper on AOP (for session repl) > - > > Key: JBCACHE-42 > URL: http://jira.jboss.com/jira/browse/JBCACHE-42 > Project: JBoss Cache > Type: Task > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Ben Wang > Priority: Minor > Fix For: 1.2.4 > > Original Estimate: 1 week > Remaining: 1 week > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-54) JBossCacheAop nees a customized interceptor option
[ http://jira.jboss.com/jira/browse/JBCACHE-54?page=history ] Bela Ban reassigned JBCACHE-54: --- Assign To: Ben Wang (was: Bela Ban) > JBossCacheAop nees a customized interceptor option > -- > > Key: JBCACHE-54 > URL: http://jira.jboss.com/jira/browse/JBCACHE-54 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Ben Wang > Fix For: 1.2.4 > > Original Estimate: 1 week, 3 days > Remaining: 1 week, 3 days > > In designing the implementation of http session repl using JBossCacheAop, > there is a need to add a customized interceptor (in addition to the > CacheInterceptor) to handle specific session request. > This feature can be generalized to a generic customized interceptor chain > that a user of aop can add to his own. Idea then is the chain (of which > starts with the CacheInterceptor) will be added as a dynamic aop interceptors. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-119) Missing notification for remove() and addChild()
[ http://jira.jboss.com/jira/browse/JBCACHE-119?page=history ] Bela Ban updated JBCACHE-119: - Fix Version: 1.2.3 (was: 1.2.2) > Missing notification for remove() and addChild() > > > Key: JBCACHE-119 > URL: http://jira.jboss.com/jira/browse/JBCACHE-119 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.3 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-103) ConfiguratorFactory#getConfigStream should not throw a AccessControlException
[ http://jira.jboss.com/jira/browse/JBCACHE-103?page=history ] Bela Ban updated JBCACHE-103: - Fix Version: 1.2.4 (was: 1.2.3) > ConfiguratorFactory#getConfigStream should not throw a AccessControlException > - > > Key: JBCACHE-103 > URL: http://jira.jboss.com/jira/browse/JBCACHE-103 > Project: JBoss Cache > Type: Bug > Versions: 2.x > Environment: JBoss 4.0.1_sp1 / JCache 2.2.7 > Reporter: Roland R?z > Assignee: Bela Ban > Fix For: 1.2.4 > > Original Estimate: 30 minutes > Remaining: 30 minutes > > Hi, > the following will cause an AccessControlException when working with a > Java security file policy that sets limited FilePermissions: > class org.jgroups.conf.ConfiguratorFactory > method > InputStream getConfigStream(String properties) throws IOException > ... > // Check to see if the properties string is the name of a file. > if (configStream == null) { > try { > configStream=new FileInputStream(properties); > } > catch(FileNotFoundException fnfe) { > // the properties string is likely not a file > } > } > If the properties are not a file but the real properties a > AccessControlException > will be thrown when checking the FilePermission that looks like this (for > example) > UDP(ip_mcast=true;ip_ttl=32;loopback=false;mcast_addr=228.1.2.3;mcast_port=12020;...) > Possibly you should check if the String properties starts with UDP. > Regards -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-118) Inefficient CacheLoader.exists() followed by CacheLoader.get()
[ http://jira.jboss.com/jira/browse/JBCACHE-118?page=history ] Bela Ban updated JBCACHE-118: - Fix Version: 1.2.4 (was: 1.2.3) > Inefficient CacheLoader.exists() followed by CacheLoader.get() > -- > > Key: JBCACHE-118 > URL: http://jira.jboss.com/jira/browse/JBCACHE-118 > Project: JBoss Cache > Type: Task > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.4 > > > I have a CacheLoader that I am using to allow a TreeCache to act as the > primary interface to a DAV/JDBC data model. Each access to the backend can be > quite expensive. I note that a CacheLoader.get() is always preceeded by a > CacheLoader.exists(), which seems redundant to me and has the unfortunate > effect of doubling the backend load. Am I missing something here? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-116) CacheLoaderInterceptor calls CacheLoader.exists() spuriously
[ http://jira.jboss.com/jira/browse/JBCACHE-116?page=history ] Bela Ban updated JBCACHE-116: - Fix Version: 1.2.4 (was: 1.2.2) > CacheLoaderInterceptor calls CacheLoader.exists() spuriously > > > Key: JBCACHE-116 > URL: http://jira.jboss.com/jira/browse/JBCACHE-116 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.4 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBCACHE-116) CacheLoaderInterceptor calls CacheLoader.exists() spuriously
[ http://jira.jboss.com/jira/browse/JBCACHE-116?page=history ] Bela Ban reopened JBCACHE-116: -- There is always a exists() followed by a get() on the CacheLoader. We should club these 2 methods together into 1 > CacheLoaderInterceptor calls CacheLoader.exists() spuriously > > > Key: JBCACHE-116 > URL: http://jira.jboss.com/jira/browse/JBCACHE-116 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-122) Convert JBoss Logger to commons-logging
Convert JBoss Logger to commons-logging Key: JBCACHE-122 URL: http://jira.jboss.com/jira/browse/JBCACHE-122 Project: JBoss Cache Type: Sub-task Reporter: Bela Ban Assigned to: Bela Ban get rid of jboss-common -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-123) Get rid of JBoss-dependent libs
Get rid of JBoss-dependent libs --- Key: JBCACHE-123 URL: http://jira.jboss.com/jira/browse/JBCACHE-123 Project: JBoss Cache Type: Sub-task Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.3 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-85) TreeCacheAop object event listener
[ http://jira.jboss.com/jira/browse/JBCACHE-85?page=history ] Bela Ban updated JBCACHE-85: Fix Version: 1.2.4 (was: 1.2.3) > TreeCacheAop object event listener > -- > > Key: JBCACHE-85 > URL: http://jira.jboss.com/jira/browse/JBCACHE-85 > Project: JBoss Cache > Type: Feature Request > Reporter: Ben Wang > Assignee: Ben Wang > Fix For: 1.2.4 > > Original Estimate: 4 days > Remaining: 4 days > > Need to add a TreeCacheAop object event listener. Currently we have TreeCache > listener to listen for individual node event. We need to listen the event at > the object level for the cache aop. This is also needed for the aop > implementation of Tomcat http session replication (fine-grained one) to > update the session related data (e.g., time stamp). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-110) Cache aop Overriding toString or hashCode will trigger stack overflow
[ http://jira.jboss.com/jira/browse/JBCACHE-110?page=history ] Bela Ban updated JBCACHE-110: - Fix Version: 1.2.4 (was: 1.2.3) > Cache aop Overriding toString or hashCode will trigger stack overflow > - > > Key: JBCACHE-110 > URL: http://jira.jboss.com/jira/browse/JBCACHE-110 > Project: JBoss Cache > Type: Bug > Versions: 1.2 > Reporter: Ben Wang > Assignee: Ben Wang > Fix For: 1.2.4 > > Original Estimate: 2 weeks > Remaining: 2 weeks > > In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is > becuase of the recursive field interecption that results. Solution is to > detect the field recusion. > Kabir has done it in: > org.jboss.aspects.dbc.DesignByContractAspect -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-36) TCP:PING, TCP transport combined with multicast discovery
[ http://jira.jboss.com/jira/browse/JGRP-36?page=history ] Bela Ban resolved JGRP-36: -- Resolution: Done Implemented as MPING. Stack would be for example TCP:MPING, check JGroups/conf/mtcp.xml for an example. MPING uses its own IP multicast socket to send and receive discovery requests/responses. Can be used in * conjuntion with a non-UDP transport, e.g. TCP. * The discovery is assymetric: discovery requests are broadcast via the multicast socket, and * received via the multicast socket by everyone in the group. However, the discovery responses are sent * back via the regular transport (e.g. TCP) to the sender (discovery request contained sender's regular address, * e.g. 192.168.0.2:7800). > TCP:PING, TCP transport combined with multicast discovery > - > > Key: JGRP-36 > URL: http://jira.jboss.com/jira/browse/JGRP-36 > Project: JGroups > Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.8 > > > Use IP multicast for discovery/merging, but TCP for transport -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBCACHE-116) CacheLoaderInterceptor calls CacheLoader.exists() spuriously
[ http://jira.jboss.com/jira/browse/JBCACHE-116?page=history ] Bela Ban closed JBCACHE-116: Resolution: Duplicate Issue duplicate of JBCACHE-118 > CacheLoaderInterceptor calls CacheLoader.exists() spuriously > > > Key: JBCACHE-116 > URL: http://jira.jboss.com/jira/browse/JBCACHE-116 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.4 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-53) JBossCacheAop can use "prepare" annotation
[ http://jira.jboss.com/jira/browse/JBCACHE-53?page=history ] Bela Ban reassigned JBCACHE-53: --- Assign To: Ben Wang (was: Bela Ban) > JBossCacheAop can use "prepare" annotation > -- > > Key: JBCACHE-53 > URL: http://jira.jboss.com/jira/browse/JBCACHE-53 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Ben Wang > Priority: Minor > Fix For: 1.2.4 > > Original Estimate: 2 days > Remaining: 2 days > > Currently, JBossCacheAop uses an external jboss-aop.xml to declare the POJO. > The latest JBossAop supports "prepare" annotation tag. We will need to test > it out and document 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=history ] Bela Ban reassigned JBCACHE-98: --- Assign To: Ben Wang (was: Bela Ban) > Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases > > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Components: Clustering > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Ben Wang > Fix For: 1.2.2 > Attachments: jboss-cache.jar > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. > In addition, there is 3.2.x release. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-7) JBossCacheAop benchmark and performance tuning
[ http://jira.jboss.com/jira/browse/JBCACHE-7?page=history ] Bela Ban updated JBCACHE-7: --- Fix Version: 1.2.4 (was: 1.2.3) > JBossCacheAop benchmark and performance tuning > -- > > Key: JBCACHE-7 > URL: http://jira.jboss.com/jira/browse/JBCACHE-7 > Project: JBoss Cache > Type: Task > Versions: 1.3 > Reporter: Bela Ban > Assignee: Ben Wang > Priority: Minor > Fix For: 1.2.4 > > Original Estimate: 6 weeks > Remaining: 6 weeks > > Test large amounts of data: should be handled by CacheLoader plus > eviction policies -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-53) JBossCacheAop can use "prepare" annotation
[ http://jira.jboss.com/jira/browse/JBCACHE-53?page=history ] Bela Ban updated JBCACHE-53: Fix Version: 1.2.4 (was: 1.2.3) > JBossCacheAop can use "prepare" annotation > -- > > Key: JBCACHE-53 > URL: http://jira.jboss.com/jira/browse/JBCACHE-53 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.4 > > Original Estimate: 2 days > Remaining: 2 days > > Currently, JBossCacheAop uses an external jboss-aop.xml to declare the POJO. > The latest JBossAop supports "prepare" annotation tag. We will need to test > it out and document 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-100) RMI-based DelegatingCacheLoader
[ http://jira.jboss.com/jira/browse/JBCACHE-100?page=history ] Bela Ban updated JBCACHE-100: - Fix Version: 1.2.4 (was: 1.2.3) > RMI-based DelegatingCacheLoader > --- > > Key: JBCACHE-100 > URL: http://jira.jboss.com/jira/browse/JBCACHE-100 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.4 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-54) JBossCacheAop nees a customized interceptor option
[ http://jira.jboss.com/jira/browse/JBCACHE-54?page=history ] Bela Ban updated JBCACHE-54: Fix Version: 1.2.4 (was: 1.2.3) > JBossCacheAop nees a customized interceptor option > -- > > Key: JBCACHE-54 > URL: http://jira.jboss.com/jira/browse/JBCACHE-54 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Bela Ban > Fix For: 1.2.4 > > Original Estimate: 1 week, 3 days > Remaining: 1 week, 3 days > > In designing the implementation of http session repl using JBossCacheAop, > there is a need to add a customized interceptor (in addition to the > CacheInterceptor) to handle specific session request. > This feature can be generalized to a generic customized interceptor chain > that a user of aop can add to his own. Idea then is the chain (of which > starts with the CacheInterceptor) will be added as a dynamic aop interceptors. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-104) Mass Removal
[ http://jira.jboss.com/jira/browse/JBCACHE-104?page=history ] Bela Ban updated JBCACHE-104: - Fix Version: 1.2.4 (was: 1.2.3) > Mass Removal > > > Key: JBCACHE-104 > URL: http://jira.jboss.com/jira/browse/JBCACHE-104 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2 > Reporter: fredatwork > Assignee: Ben Wang > Fix For: 1.2.4 > > > Hello, > I would like to propose to enhance JBossCache API with a mass-removal > function : > Let's say I entered several objects in an AOP cache : > cache.putObject("/root/1", object1); > cache.putObject("/root/2", object2); > .../... > cache.putObject("/root/999", object999); > I would like to be able to remove masseively all objects under the "/root" > frq, with a single method call. > The idea here is to be able to reset whole regions of the cache by removing > all objects contained in this region. For instance, a servlet init method > could use this new method to reset a cache dedicated to a particular > enterprise application. > Whiout this method, there is no way to reseta cache region. With current 1.2 > version, you have to keep track of individual objects in order to remove them > one after the other one. > Note: Ben Wang proposed me to create this feature request so he can add it to > the roadmpa. See > http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3868494#3868494. > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-121) Update JBoss head, 3.x and 4.x with jboss-cache.jar
Update JBoss head, 3.x and 4.x with jboss-cache.jar --- Key: JBCACHE-121 URL: http://jira.jboss.com/jira/browse/JBCACHE-121 Project: JBoss Cache Type: Task Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.3 Also unlink _jboss_cache module, modify integration tests -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-117) Unnecessary lock acquisition with IsolationLevel.NONE
[ http://jira.jboss.com/jira/browse/JBCACHE-117?page=history ] Bela Ban updated JBCACHE-117: - Fix Version: 1.2.3 (was: 1.2.2) > Unnecessary lock acquisition with IsolationLevel.NONE > - > > Key: JBCACHE-117 > URL: http://jira.jboss.com/jira/browse/JBCACHE-117 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > > java.lang.IllegalStateException: addWriter(): owner already existed > at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) > at org.jboss.cache.Node.acquireWriteLock(Node.java:483) > at org.jboss.cache.Node.acquire(Node.java:440) > at > org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) > at > org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) > > at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) > 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:324) > at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) > at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) > at > org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) > > at > org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) > > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) > > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) > > at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) > at java.lang.Thread.run(Thread.java:534) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-20) Address translation in transport (NAT support)
[ http://jira.jboss.com/jira/browse/JGRP-20?page=history ] Bela Ban updated JGRP-20: - Summary: Address translation in transport (NAT support) (was: Address translation in transport) > Address translation in transport (NAT support) > -- > > Key: JGRP-20 > URL: http://jira.jboss.com/jira/browse/JGRP-20 > Project: JGroups > Type: Feature Request > Versions: 2.2.8 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.2.9 > > Original Estimate: 1 week > Remaining: 1 week > > On multi-homed systems, the identity of a member is bound to a NIC (either > chosen by the OS, or by the > user through bind_addr): Address. When a message is sent, the msg contains > this address as the sender's > address. Responses go to the same address. > However, if that NIC breaks, and the sender's OS chooses a different NIC for > the datagram packets, the > receiver will still send the response back to the old address (the identity > of the sender cannot > change). > If we set the sender's address in any Message on *reception* of the message, > we would be able to send > the response back to a valid NIC in the above case. However, this means the > *identity* of the sender > changes, which JGroups cannot handle. > SOLUTION I: we could introduce a logical address, which contains the physical > address of the NIC > through which it was sent. Problem: a lot of code would have to change. > SOLUTION II: we maintain, in each transport, a table of sender's address as > defined in the Message, and > physical address of the {Datagram,Multicast}Packet received. Whenever we send > a unicast message, we get > the destination address from this table through a lookup in which > dest_msg.dest_addr is the key. > We need to reap the table every now and then to purge old addresses, we could > use view changes to do > so. > Example for SOLUTION II: > - Member P: address=1.2.3.4: > - P's box has 2 NICs: 1.2.3.4 and 5.6.7.8 > - Receiver R receives a message from P: P.src_addr=1.2.3.4:, datagram's > address is 1234: > - R doesn't add an entry to the translation table, because the addresses are > the same > - R sends a response: it looks up 1.2.3.4: (dst) in the translation table > - There is no entry, therefore R sends the response to 1.2.3.4: > - P's NIC 1.2.3.4 is unplugged > - P sends a message through NIC 5.6.7.8 > - R receives a message M.src_addr=1.2.3.4:, datagram's address is > 5.6.7.8: > - R adds an entry to its translation table: 1.2.3.4: --> 5.6.7.8: > - R sends a response to 1.2.3.4:, since there is an entry for > 1.2.3.4:, it uses 5.6.7.8: > as the destination address of the datagram packet > SOLUTION II allows us to reuse the existing code, but provides for changing > underlying IP addresses. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316550 ] Bela Ban commented on JBCACHE-98: - done > Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases > > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Components: Clustering > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Bela Ban > Fix For: 1.2.2 > Attachments: jboss-cache.jar > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. > In addition, there is 3.2.x release. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=history ] Bela Ban updated JBCACHE-98: Attachment: jboss-cache.jar attached JBossCache 1.2.2beta > Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases > > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Components: Clustering > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Bela Ban > Fix For: 1.2.2 > Attachments: jboss-cache.jar > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. > In addition, there is 3.2.x release. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316538 ] Bela Ban commented on JBCACHE-98: - no, it is not: java -jar jboss-cache.jar will reveal the version # > Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases > -- > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Bela Ban > Fix For: 1.2.2 > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316531 ] Bela Ban commented on JBCACHE-98: - Looks like 4.0.2 might be delayed by 1 week, this gives me time to release 1.2.2 and create a thirdparty lib jboss-cache.jar that 4.0.2 will use. Clebert: I can already give you the jboss-cache.jar file for testing purposes, you'd simply replace server//all/lib/jboss-cache.jar with it, and could let me know whether the tests pass. This way, we could parallelize integration into 4.0.2 > Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases > -- > > Key: JBCACHE-98 > URL: http://jira.jboss.com/jira/browse/JBCACHE-98 > Project: JBoss Cache > Type: Support Patch > Versions: 1.2 > Environment: should work in any environment > Reporter: Luc Texier > Assignee: Bela Ban > Fix For: 1.2.2 > > > Some customers have expressed the wish to take avantages of the > optimizations/bug fixes/enhancements being implemented in the latest releases > of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). > Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 > and JBossAS 4.0.1. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-119) Missing notification for remove() and addChild()
[ http://jira.jboss.com/jira/browse/JBCACHE-119?page=history ] Bela Ban resolved JBCACHE-119: -- Resolution: Done Testcase is TreeCacheListenerTest > Missing notification for remove() and addChild() > > > Key: JBCACHE-119 > URL: http://jira.jboss.com/jira/browse/JBCACHE-119 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-119) Missing notification for remove() and addChild()
Missing notification for remove() and addChild() Key: JBCACHE-119 URL: http://jira.jboss.com/jira/browse/JBCACHE-119 Project: JBoss Cache Type: Bug Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Priority: Minor Fix For: 1.2.2 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-118) Inefficient CacheLoader.exists() followed by CacheLoader.get()
[ http://jira.jboss.com/jira/browse/JBCACHE-118?page=history ] Bela Ban updated JBCACHE-118: - Fix Version: 1.2.3 (was: 1.2.2) > Inefficient CacheLoader.exists() followed by CacheLoader.get() > -- > > Key: JBCACHE-118 > URL: http://jira.jboss.com/jira/browse/JBCACHE-118 > Project: JBoss Cache > Type: Task > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.3 > > > I have a CacheLoader that I am using to allow a TreeCache to act as the > primary interface to a DAV/JDBC data model. Each access to the backend can be > quite expensive. I note that a CacheLoader.get() is always preceeded by a > CacheLoader.exists(), which seems redundant to me and has the unfortunate > effect of doubling the backend load. Am I missing something here? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-118) Inefficient CacheLoader.exists() followed by CacheLoader.get()
Inefficient CacheLoader.exists() followed by CacheLoader.get() -- Key: JBCACHE-118 URL: http://jira.jboss.com/jira/browse/JBCACHE-118 Project: JBoss Cache Type: Task Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Priority: Minor Fix For: 1.2.2 I have a CacheLoader that I am using to allow a TreeCache to act as the primary interface to a DAV/JDBC data model. Each access to the backend can be quite expensive. I note that a CacheLoader.get() is always preceeded by a CacheLoader.exists(), which seems redundant to me and has the unfortunate effect of doubling the backend load. Am I missing something here? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-117) Unnecessary lock acquisition with IsolationLevel.NONE
[ http://jira.jboss.com/jira/browse/JBCACHE-117?page=history ] Bela Ban resolved JBCACHE-117: -- Resolution: Done LockInterceptor.lock() does *not* acquire a lock if isolation level == NONE > Unnecessary lock acquisition with IsolationLevel.NONE > - > > Key: JBCACHE-117 > URL: http://jira.jboss.com/jira/browse/JBCACHE-117 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > > java.lang.IllegalStateException: addWriter(): owner already existed > at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) > at org.jboss.cache.Node.acquireWriteLock(Node.java:483) > at org.jboss.cache.Node.acquire(Node.java:440) > at > org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) > at > org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) > > at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) > 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:324) > at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) > at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) > at > org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) > > at > org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) > > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) > > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) > > at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) > at java.lang.Thread.run(Thread.java:534) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-117) Unnecessary lock acquisition with IsolationLevel.NONE
[ http://jira.jboss.com/jira/browse/JBCACHE-117?page=comments#action_12316510 ] Bela Ban commented on JBCACHE-117: -- added test case IsolationLevelNoneTest > Unnecessary lock acquisition with IsolationLevel.NONE > - > > Key: JBCACHE-117 > URL: http://jira.jboss.com/jira/browse/JBCACHE-117 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > > java.lang.IllegalStateException: addWriter(): owner already existed > at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) > at org.jboss.cache.Node.acquireWriteLock(Node.java:483) > at org.jboss.cache.Node.acquire(Node.java:440) > at > org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) > at > org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at > org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) > > at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) > 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:324) > at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) > at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) > at > org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) > > at > org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) > > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) > > at > org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) > > at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) > at java.lang.Thread.run(Thread.java:534) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-117) Unnecessary lock acquisition with IsolationLevel.NONE
Unnecessary lock acquisition with IsolationLevel.NONE - Key: JBCACHE-117 URL: http://jira.jboss.com/jira/browse/JBCACHE-117 Project: JBoss Cache Type: Bug Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.2 java.lang.IllegalStateException: addWriter(): owner already existed at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175) at org.jboss.cache.Node.acquireWriteLock(Node.java:483) at org.jboss.cache.Node.acquire(Node.java:440) at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240) at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) at org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217) at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682) 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:324) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) at java.lang.Thread.run(Thread.java:534) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-116) CacheLoaderInterceptor calls CacheLoader.exists() spuriously
CacheLoaderInterceptor calls CacheLoader.exists() spuriously Key: JBCACHE-116 URL: http://jira.jboss.com/jira/browse/JBCACHE-116 Project: JBoss Cache Type: Bug Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.2 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-116) CacheLoaderInterceptor calls CacheLoader.exists() spuriously
[ http://jira.jboss.com/jira/browse/JBCACHE-116?page=history ] Bela Ban resolved JBCACHE-116: -- Resolution: Done accepted patch > CacheLoaderInterceptor calls CacheLoader.exists() spuriously > > > Key: JBCACHE-116 > URL: http://jira.jboss.com/jira/browse/JBCACHE-116 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-53) JBossCacheAop can use "prepare" annotation
[ http://jira.jboss.com/jira/browse/JBCACHE-53?page=history ] Bela Ban updated JBCACHE-53: Fix Version: 1.2.3 (was: 1.2.2) > JBossCacheAop can use "prepare" annotation > -- > > Key: JBCACHE-53 > URL: http://jira.jboss.com/jira/browse/JBCACHE-53 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Bela Ban > Priority: Minor > Fix For: 1.2.3 > > Original Estimate: 2 days > Remaining: 2 days > > Currently, JBossCacheAop uses an external jboss-aop.xml to declare the POJO. > The latest JBossAop supports "prepare" annotation tag. We will need to test > it out and document 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-42) White paper on AOP (for session repl)
[ http://jira.jboss.com/jira/browse/JBCACHE-42?page=history ] Bela Ban updated JBCACHE-42: Fix Version: 1.2.3 (was: 1.2.2) > White paper on AOP (for session repl) > - > > Key: JBCACHE-42 > URL: http://jira.jboss.com/jira/browse/JBCACHE-42 > Project: JBoss Cache > Type: Task > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Ben Wang > Priority: Minor > Fix For: 1.2.3 > > Original Estimate: 1 week > Remaining: 1 week > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-7) JBossCacheAop benchmark and performance tuning
[ http://jira.jboss.com/jira/browse/JBCACHE-7?page=history ] Bela Ban updated JBCACHE-7: --- Fix Version: 1.2.3 (was: 1.2.2) > JBossCacheAop benchmark and performance tuning > -- > > Key: JBCACHE-7 > URL: http://jira.jboss.com/jira/browse/JBCACHE-7 > Project: JBoss Cache > Type: Task > Versions: 1.3 > Reporter: Bela Ban > Assignee: Ben Wang > Priority: Minor > Fix For: 1.2.3 > > Original Estimate: 6 weeks > Remaining: 6 weeks > > Test large amounts of data: should be handled by CacheLoader plus > eviction policies -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-85) TreeCacheAop object event listener
[ http://jira.jboss.com/jira/browse/JBCACHE-85?page=history ] Bela Ban updated JBCACHE-85: Fix Version: 1.2.3 (was: 1.2.2) > TreeCacheAop object event listener > -- > > Key: JBCACHE-85 > URL: http://jira.jboss.com/jira/browse/JBCACHE-85 > Project: JBoss Cache > Type: Feature Request > Reporter: Ben Wang > Assignee: Ben Wang > Fix For: 1.2.3 > > Original Estimate: 4 days > Remaining: 4 days > > Need to add a TreeCacheAop object event listener. Currently we have TreeCache > listener to listen for individual node event. We need to listen the event at > the object level for the cache aop. This is also needed for the aop > implementation of Tomcat http session replication (fine-grained one) to > update the session related data (e.g., time stamp). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-100) RMI-based DelegatingCacheLoader
[ http://jira.jboss.com/jira/browse/JBCACHE-100?page=history ] Bela Ban updated JBCACHE-100: - Fix Version: 1.2.3 (was: 1.2.2) > RMI-based DelegatingCacheLoader > --- > > Key: JBCACHE-100 > URL: http://jira.jboss.com/jira/browse/JBCACHE-100 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.3 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-104) Mass Removal
[ http://jira.jboss.com/jira/browse/JBCACHE-104?page=history ] Bela Ban updated JBCACHE-104: - Fix Version: 1.2.3 (was: 1.2.2) > Mass Removal > > > Key: JBCACHE-104 > URL: http://jira.jboss.com/jira/browse/JBCACHE-104 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2 > Reporter: fredatwork > Assignee: Ben Wang > Fix For: 1.2.3 > > > Hello, > I would like to propose to enhance JBossCache API with a mass-removal > function : > Let's say I entered several objects in an AOP cache : > cache.putObject("/root/1", object1); > cache.putObject("/root/2", object2); > .../... > cache.putObject("/root/999", object999); > I would like to be able to remove masseively all objects under the "/root" > frq, with a single method call. > The idea here is to be able to reset whole regions of the cache by removing > all objects contained in this region. For instance, a servlet init method > could use this new method to reset a cache dedicated to a particular > enterprise application. > Whiout this method, there is no way to reseta cache region. With current 1.2 > version, you have to keep track of individual objects in order to remove them > one after the other one. > Note: Ben Wang proposed me to create this feature request so he can add it to > the roadmpa. See > http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3868494#3868494. > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-54) JBossCacheAop nees a customized interceptor option
[ http://jira.jboss.com/jira/browse/JBCACHE-54?page=history ] Bela Ban updated JBCACHE-54: Fix Version: 1.2.3 (was: 1.2.2) > JBossCacheAop nees a customized interceptor option > -- > > Key: JBCACHE-54 > URL: http://jira.jboss.com/jira/browse/JBCACHE-54 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Bela Ban > Fix For: 1.2.3 > > Original Estimate: 1 week, 3 days > Remaining: 1 week, 3 days > > In designing the implementation of http session repl using JBossCacheAop, > there is a need to add a customized interceptor (in addition to the > CacheInterceptor) to handle specific session request. > This feature can be generalized to a generic customized interceptor chain > that a user of aop can add to his own. Idea then is the chain (of which > starts with the CacheInterceptor) will be added as a dynamic aop interceptors. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-103) ConfiguratorFactory#getConfigStream should not throw a AccessControlException
[ http://jira.jboss.com/jira/browse/JBCACHE-103?page=history ] Bela Ban updated JBCACHE-103: - Fix Version: 1.2.3 (was: 1.2.2) > ConfiguratorFactory#getConfigStream should not throw a AccessControlException > - > > Key: JBCACHE-103 > URL: http://jira.jboss.com/jira/browse/JBCACHE-103 > Project: JBoss Cache > Type: Bug > Versions: 2.x > Environment: JBoss 4.0.1_sp1 / JCache 2.2.7 > Reporter: Roland R?z > Assignee: Bela Ban > Fix For: 1.2.3 > > Original Estimate: 30 minutes > Remaining: 30 minutes > > Hi, > the following will cause an AccessControlException when working with a > Java security file policy that sets limited FilePermissions: > class org.jgroups.conf.ConfiguratorFactory > method > InputStream getConfigStream(String properties) throws IOException > ... > // Check to see if the properties string is the name of a file. > if (configStream == null) { > try { > configStream=new FileInputStream(properties); > } > catch(FileNotFoundException fnfe) { > // the properties string is likely not a file > } > } > If the properties are not a file but the real properties a > AccessControlException > will be thrown when checking the FilePermission that looks like this (for > example) > UDP(ip_mcast=true;ip_ttl=32;loopback=false;mcast_addr=228.1.2.3;mcast_port=12020;...) > Possibly you should check if the String properties starts with UDP. > Regards -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-110) Cache aop Overriding toString or hashCode will trigger stack overflow
[ http://jira.jboss.com/jira/browse/JBCACHE-110?page=history ] Bela Ban updated JBCACHE-110: - Fix Version: 1.2.3 (was: 1.2.2) > Cache aop Overriding toString or hashCode will trigger stack overflow > - > > Key: JBCACHE-110 > URL: http://jira.jboss.com/jira/browse/JBCACHE-110 > Project: JBoss Cache > Type: Bug > Versions: 1.2 > Reporter: Ben Wang > Assignee: Ben Wang > Fix For: 1.2.3 > > Original Estimate: 2 weeks > Remaining: 2 weeks > > In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is > becuase of the recursive field interecption that results. Solution is to > detect the field recusion. > Kabir has done it in: > org.jboss.aspects.dbc.DesignByContractAspect -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=comments#action_12316432 ] Bela Ban commented on JBAS-1579: Fixed all classes in org.jboss.cache package > Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes > - > > Key: JBAS-1579 > URL: http://jira.jboss.com/jira/browse/JBAS-1579 > Project: JBoss Application Server > Type: Bug > Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 > Reporter: Scott M Stark > Assignee: Clebert Suconic > Priority: Blocker > Fix For: JBossAS-4.0.2 Final > Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip, > compatibilityCheckProposedSourceCde.zip > > > I'm seeing incomptibilities between versions that are simply due to the fact > that Serializable/Externalizable classes are letting their serialVersionUIDs > float instead of explicitly defining them. We need to get this cleaned up. > There should not be a single Serializable/Externalizable class that does not > fix its serialVersionUID and then take responsibility for maintaining > compatibility with the indicated version. > The attached SerializableHasSerialVersionUIDField.zip unzips to create a > SerializableHasSerialVersionUIDField-index.html and > SerializableHasSerialVersionUIDField directory which is a report of all > classes in the 4.0 codebase that are not defining a serialVersionUID as they > should. > The JDK object serialization spec defines all you need to know about the apis > and contracts for object serialization: > http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html > In particular, Versioning of Serializable Objects: > http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 > talks about binary compatibility and what is available to manage 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-3) Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean
[ http://jira.jboss.com/jira/browse/JBCACHE-3?page=history ] Bela Ban resolved JBCACHE-3: Resolution: Duplicate Issue Duplicate of JBCACHE-43 > Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean > - > > Key: JBCACHE-3 > URL: http://jira.jboss.com/jira/browse/JBCACHE-3 > Project: JBoss Cache > Type: Feature Request > Versions: 1.3 > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 1.3 > > Original Estimate: 2 weeks > Remaining: 2 weeks > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-115) beforeEviction() callback
beforeEviction() callback - Key: JBCACHE-115 URL: http://jira.jboss.com/jira/browse/JBCACHE-115 Project: JBoss Cache Type: Feature Request Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.3 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-114) Standalone Build
[ http://jira.jboss.com/jira/browse/JBCACHE-114?page=history ] Bela Ban reassigned JBCACHE-114: Assign To: Bela Ban (was: Ryan Campbell) > Standalone Build > > > Key: JBCACHE-114 > URL: http://jira.jboss.com/jira/browse/JBCACHE-114 > Project: JBoss Cache > Type: Task > Reporter: Ryan Campbell > Assignee: Bela Ban > > > Ben and I have a plan for moving jboss-cache to a standalone build before the > new build system is complete. > 1. Bela eliminates dependencies > 2. Ben creates basic standalone build.xml and adds jboss-cache.jar to > jboss-thirdparty > 3. Ryan removes cache from jboss-head, jboss-3.2 and jboss-4.0 cvs aliases > 3. Ryan adds nightly jboss-cache standalone build to cruisecontrol > Once jboss-cache has non-container tests migrated from testsuite... > 1. Ben/Bela add tests to jboss-cache testsuite > 2. Ryan adds test target to nightly cruisecontrol > Ben said there will eventually be cache integration code in the AS, at which > point: > 1. Create a the new integration module (jboss-as-cache) > 2. Add it to the cvs aliases as "cache" -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBCACHE-113) ConcurrentModificationException in TransactionTable
[ http://jira.jboss.com/jira/browse/JBCACHE-113?page=history ] Bela Ban closed JBCACHE-113: Resolution: Done This is fixed in 1.2.2 (not yet checked in) > ConcurrentModificationException in TransactionTable > --- > > Key: JBCACHE-113 > URL: http://jira.jboss.com/jira/browse/JBCACHE-113 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-47) Support for IPv6
Support for IPv6 Key: JGRP-47 URL: http://jira.jboss.com/jira/browse/JGRP-47 Project: JGroups Type: Feature Request Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.3 Requires changes to IpAddress, maybe Ipv6Address (subclass of IpAddress) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-46) RpcDispatcher eats Throwables
RpcDispatcher eats Throwables - Key: JGRP-46 URL: http://jira.jboss.com/jira/browse/JGRP-46 Project: JGroups Type: Bug Reporter: Bela Ban Assigned to: Bela Ban Fix For: 2.2.8 handle() re-throws Exception, but eats Throwables -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-113) ConcurrentModificationException in TransactionTable
ConcurrentModificationException in TransactionTable --- Key: JBCACHE-113 URL: http://jira.jboss.com/jira/browse/JBCACHE-113 Project: JBoss Cache Type: Bug Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.2 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-113) ConcurrentModificationException in TransactionTable
[ http://jira.jboss.com/jira/browse/JBCACHE-113?page=history ] Bela Ban resolved JBCACHE-113: -- Resolution: Done Fixed by switching HashMap to ConcurrentReaderHashMap > ConcurrentModificationException in TransactionTable > --- > > Key: JBCACHE-113 > URL: http://jira.jboss.com/jira/browse/JBCACHE-113 > Project: JBoss Cache > Type: Bug > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-112) Added putFailFast(Fqn, ...)
[ http://jira.jboss.com/jira/browse/JBCACHE-112?page=history ] Bela Ban resolved JBCACHE-112: -- Resolution: Done > Added putFailFast(Fqn, ...) > --- > > Key: JBCACHE-112 > URL: http://jira.jboss.com/jira/browse/JBCACHE-112 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.2.2 > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-112) Added putFailFast(Fqn, ...)
Added putFailFast(Fqn, ...) --- Key: JBCACHE-112 URL: http://jira.jboss.com/jira/browse/JBCACHE-112 Project: JBoss Cache Type: Feature Request Versions: 1.2.1 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.2 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-57) Interfaces for accessing JBossCache
[ http://jira.jboss.com/jira/browse/JBCACHE-57?page=history ] Bela Ban updated JBCACHE-57: Fix Version: 1.3 (was: 1.4) > Interfaces for accessing JBossCache > --- > > Key: JBCACHE-57 > URL: http://jira.jboss.com/jira/browse/JBCACHE-57 > Project: JBoss Cache > Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.3 > > Original Estimate: 1 week, 3 days > Remaining: 1 week, 3 days > > - Access JBossCache through interfaces, not impl > - Factory-based approach, use either TreeCache or TreeCacheAop: > factory.createCache(XML file) > - How to provide JMX access ? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBCACHE-52) Use ant docbook build for doc generation
[ http://jira.jboss.com/jira/browse/JBCACHE-52?page=history ] Bela Ban resolved JBCACHE-52: - Resolution: Done done by Norman Richards and Michael Yuan > Use ant docbook build for doc generation > > > Key: JBCACHE-52 > URL: http://jira.jboss.com/jira/browse/JBCACHE-52 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Ben Wang > Assignee: Ben Wang > Priority: Minor > Fix For: 1.3 > > Original Estimate: 2 days > Remaining: 2 days > > We need to automatically generate doc from docbook files using ant build. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-106) Override default properties on a method call basis
[ http://jira.jboss.com/jira/browse/JBCACHE-106?page=comments#action_12316092 ] Bela Ban commented on JBCACHE-106: -- Another option: dirty access, acquire no locks at all > Override default properties on a method call basis > -- > > Key: JBCACHE-106 > URL: http://jira.jboss.com/jira/browse/JBCACHE-106 > Project: JBoss Cache > Type: Feature Request > Versions: 1.2.1 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 1.3 > > > Allows to make an asynchronous call although the config is synchronous > (SYNC_REPL). > Possible properties to provide: > - mode: local or replicated > - replMode: sync or async > - timeout > Prototype: > put(tx, FQN, key, value, Options) > Options would allow a caller to override specific properties -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development