[JBoss-dev] [JBoss JIRA] Created: (JGRP-54) Remove flow control from UNICAST (provided by FC)

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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)

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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()

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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()

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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)

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

 [ 
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()

[Bela Ban (JIRA)]

 [ 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()

[Bela Ban (JIRA)]

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()

[Bela Ban (JIRA)]

 [ 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()

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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)

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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, ...)

[Bela Ban (JIRA)]

 [ 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, ...)

[Bela Ban (JIRA)]

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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 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

[Bela Ban (JIRA)]

 [ 
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