[JBoss JIRA] Commented: (JBCACHE-486) Optimize activations
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-486?page=comments#action_12369142 ]
Manik Surtani commented on JBCACHE-486:
---------------------------------------
Not true, loader.exists() is still necessary since the loader may not remove the node due to children being present, even if the node has been loaded.
> Optimize activations
> --------------------
>
> Key: JBCACHE-486
> URL: http://jira.jboss.com/jira/browse/JBCACHE-486
> Project: JBoss Cache
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 1.3.0.GA
> Reporter: Jerry Gauthier
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: 2.0.0.GA
>
>
> JBCACHE-420 notes that activation processing is performed excessively. The resolution of JBCACHE-420 eliminates the excessive activations but it doesn't resolve the following optimization issue.
> The ActivationInterceptor can't readily determine whether a node has been passivated because the cache loading operation occurs in the CacheLoaderInterceptor. Consequently the activation interceptor invokes loader.exists(node) to ascertain whether the node has been passivated. This works properly but is an unnecessary operation as the CacheLoader interceptor executes immediately prior to the Activation interceptor and it makes a similar determination. This determination can be expensive as itmay involve performing database operations (e.g., for a JDBC cache loader).
> It's desirable to eliminate the loader.exists(node) invocation in the Activation interceptor to optimize performance. One possible way to accomplish this would be to add a pesudo attribute __PASSIVATED__
> to the node's hashmap (similar to __INITIALIZED__) whenever a node has been passivated, and remove it again when
> activated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Reopened: (JBCACHE-486) Optimize activations
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-486?page=all ]
Manik Surtani reopened JBCACHE-486:
-----------------------------------
> Optimize activations
> --------------------
>
> Key: JBCACHE-486
> URL: http://jira.jboss.com/jira/browse/JBCACHE-486
> Project: JBoss Cache
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 1.3.0.GA
> Reporter: Jerry Gauthier
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: 2.0.0.GA
>
>
> JBCACHE-420 notes that activation processing is performed excessively. The resolution of JBCACHE-420 eliminates the excessive activations but it doesn't resolve the following optimization issue.
> The ActivationInterceptor can't readily determine whether a node has been passivated because the cache loading operation occurs in the CacheLoaderInterceptor. Consequently the activation interceptor invokes loader.exists(node) to ascertain whether the node has been passivated. This works properly but is an unnecessary operation as the CacheLoader interceptor executes immediately prior to the Activation interceptor and it makes a similar determination. This determination can be expensive as itmay involve performing database operations (e.g., for a JDBC cache loader).
> It's desirable to eliminate the loader.exists(node) invocation in the Activation interceptor to optimize performance. One possible way to accomplish this would be to add a pesudo attribute __PASSIVATED__
> to the node's hashmap (similar to __INITIALIZED__) whenever a node has been passivated, and remove it again when
> activated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Updated: (JGRP-135) Common discovery multicast address/port
by Jimmy Wilson (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-135?page=all ]
Jimmy Wilson updated JGRP-135:
------------------------------
Description:
In TP, we create a listener on 224.0.0.75:7500 (hard-coded, fixed multicast address/port). When pinged, it returns information in key/value format, such as
- clusterName: DefaultPartition
- address: 192.168.5.1
- version: 2.2.9
- members: 192.168.5.1, 192.168.34.2, 192.168.0.2
- configuration: "UDP:FD:GMS"
The format is simple: keys and values are both strings, so we can have programmatic discovery of clusters.
If the returned information is > 1472 bytes (ethernet MTU - IP and UDP datagram size), then we simply break up the reply into multiple packets, each packet has to have the clusterName and address fields present though, to identify them.
This might be used in the future to not just query information, but also submit commands. To ensure future compatibility, make sure to design the format in an extensible way, e.g. keys and values are strings.
was:
In TP, we create a listener on 224.0.0.5:7500 (hard-coded, fixed multicast address/port). When pinged, it returns information in key/value format, such as
- clusterName: DefaultPartition
- address: 192.168.5.1
- version: 2.2.9
- members: 192.168.5.1, 192.168.34.2, 192.168.0.2
- configuration: "UDP:FD:GMS"
The format is simple: keys and values are both strings, so we can have programmatic discovery of clusters.
If the returned information is > 1472 bytes (ethernet MTU - IP and UDP datagram size), then we simply break up the reply into multiple packets, each packet has to have the clusterName and address fields present though, to identify them.
This might be used in the future to not just query information, but also submit commands. To ensure future compatibility, make sure to design the format in an extensible way, e.g. keys and values are strings.
Fixed typo.
> Common discovery multicast address/port
> ---------------------------------------
>
> Key: JGRP-135
> URL: http://jira.jboss.com/jira/browse/JGRP-135
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.2.9
>
>
> In TP, we create a listener on 224.0.0.75:7500 (hard-coded, fixed multicast address/port). When pinged, it returns information in key/value format, such as
> - clusterName: DefaultPartition
> - address: 192.168.5.1
> - version: 2.2.9
> - members: 192.168.5.1, 192.168.34.2, 192.168.0.2
> - configuration: "UDP:FD:GMS"
> The format is simple: keys and values are both strings, so we can have programmatic discovery of clusters.
> If the returned information is > 1472 bytes (ethernet MTU - IP and UDP datagram size), then we simply break up the reply into multiple packets, each packet has to have the clusterName and address fields present though, to identify them.
> This might be used in the future to not just query information, but also submit commands. To ensure future compatibility, make sure to design the format in an extensible way, e.g. keys and values are strings.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Created: (JBREM-777) Add quiet="true" in clean task of build.xml
by Ron Sigal (JIRA)
Add quiet="true" in clean task of build.xml
-------------------------------------------
Key: JBREM-777
URL: http://jira.jboss.com/jira/browse/JBREM-777
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Minor
Fix For: 2.4.0.Beta1 (Pinto)
When the Remoting builds run on cruisecontrol, occasionally they fail because they are unable to delete a file in the output directory, resulting in messages such as
Buildfile: ../checkout/jboss-remoting-testsuite-1.5/build.xml
get-jvm:
configure:
clean:
[delete] Deleting directory /services/cruisecontrol/work/checkout/jboss-remoting-testsuite-1.5/output
BUILD FAILED
/services/cruisecontrol/work/checkout/jboss-remoting-testsuite-1.5/build.xml:2433: Unable to delete file /services/cruisecontrol/work/checkout/jboss-remoting-testsuite-1.5/output/lib/.nfs0000000000d08087000396e8
quiet="true" should be added to <delete> in the clean task.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Commented: (JGRP-236) Combine join and state transfer
by Vladimir Blagojevic (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-236?page=comments#action_12369126 ]
Vladimir Blagojevic commented on JGRP-236:
------------------------------------------
Implementing JChannel#connect(String cluster_name, Address target, String state_id, long timeout)
In JChannel#connect client finds initial members and determines coordinator (JGRP-420)
In JChannel#connect client requests from coordinator to do first flush phase on its behalf and does not proceed until coordinator responds that first flush phase succeeded (current surviving members are flushed and blocked down)
In JChannel#connect client sends down CONNECT_WITH_TRANSFER event
In ClientGmsImpl client traps CONNECT_WITH_TRANSFER and sends JOIN_WITH_TRANSFER (or JOIN with transfer flag) to coordinator (no need to detemine coordinator;already done in first step)
Coordinator handles JOIN_WITH_TRANSFER (or JOIN with transfer flag) similarly as regular JOIN except we change handleMembershipChange to include use_flush boolean parameter (thus coordinator will not request another flush)
Coordinator invokes handleMembershipChange where use_flush is false, new view is determined and sent; acked by members
In JChannel#connect state is requested by joining client which sends down GET_STATE (StateTransferInfo contains use_flush flag which is false;no flush is thus requested)
In JChannel#connect state transfer succeeds or fails
In JChannel#connect requests stop flush; both surviving members and new member are unblocked down
In JChannel#connect returns
Multiple concurrent joins where some joinging members require transfer and some not is handled by CoordGmsImpl#handleMembershipChange. As soon as we have at least one member requesting join and state transfer we need to invoke CoordGmsImpl#handleMembershipChange with use_flush parameter being false since that member already triggered flush (see step 2).
> Combine join and state transfer
> -------------------------------
>
> Key: JGRP-236
> URL: http://jira.jboss.com/jira/browse/JGRP-236
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
> the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
> we send it back to the joining member(s), and the RESUME sending messages
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Updated: (JGRP-236) Combine join and state transfer
by Vladimir Blagojevic (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-236?page=all ]
Vladimir Blagojevic updated JGRP-236:
-------------------------------------
Comment: was deleted
> Combine join and state transfer
> -------------------------------
>
> Key: JGRP-236
> URL: http://jira.jboss.com/jira/browse/JGRP-236
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
> the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
> we send it back to the joining member(s), and the RESUME sending messages
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Commented: (JGRP-236) Combine join and state transfer
by Vladimir Blagojevic (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-236?page=comments#action_12369119 ]
Vladimir Blagojevic commented on JGRP-236:
------------------------------------------
How are we going to handle multiple concurrent joins(view bundling) where some joining members require transfer and others not?
> Combine join and state transfer
> -------------------------------
>
> Key: JGRP-236
> URL: http://jira.jboss.com/jira/browse/JGRP-236
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
> the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
> we send it back to the joining member(s), and the RESUME sending messages
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Commented: (JGRP-236) Combine join and state transfer
by Vladimir Blagojevic (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-236?page=comments#action_12369118 ]
Vladimir Blagojevic commented on JGRP-236:
------------------------------------------
Implementing JGRP-420 first would give us more options on resolving this issue.
> Combine join and state transfer
> -------------------------------
>
> Key: JGRP-236
> URL: http://jira.jboss.com/jira/browse/JGRP-236
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> Add an additional connect(String group_name, boolean fetch_state, String state_id) method to Channel, so that we can combine joining and state transfer into 1 operation. This also requires only 1 FLUSH phase.
> The state would be returned either via pulling with Channel.receive() or pushing the setState() method in a registered Receiver/MessageListener.
> - The JOIN_REQ contains the boolean
> - The algorithm in GMS is the same as the two described above, except that before multicasting the new view and sending
> the JOIN_RSPs and LEAVE_RSPs, we ask the application for its state (GET_APPLSTATE) and when received (GET_APPLSTATE_OK),
> we send it back to the joining member(s), and the RESUME sending messages
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years