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