[JBoss JIRA] (WFCORE-3524) Attempt to initialize the latest Extension parser if that has been registered are suppliers
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3524:
----------------------------------------
Summary: Attempt to initialize the latest Extension parser if that has been registered are suppliers
Key: WFCORE-3524
URL: https://issues.jboss.org/browse/WFCORE-3524
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.
I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.
To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3523) Don't initialize extension parsers on a domain server
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3523:
----------------------------------------
Summary: Don't initialize extension parsers on a domain server
Key: WFCORE-3523
URL: https://issues.jboss.org/browse/WFCORE-3523
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2245:
--------------------------------------
Will you be able to make J GROUP writes only its own address to DB or just the new view or latest
> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
> Key: JGRP-2245
> URL: https://issues.jboss.org/browse/JGRP-2245
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.8
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> // remove all files which are not from the current members
> protected void handleView(View new_view, View old_view, boolean coord_changed) {
> if(is_coord) {
> if(coord_changed) {
> if(remove_all_data_on_view_change)
> removeAll(cluster_name);
> else if(remove_old_coords_on_view_change) {
> Address old_coord=old_view != null? old_view.getCreator() : null;
> if(old_coord != null)
> remove(cluster_name, old_coord);
> }
> }
> if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
> writeAll();
> if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
> startInfoWriter();
> }
> }
> else if(coord_changed) // I'm no longer the coordinator
> remove(cluster_name, local_addr);
> }
> 4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar updated JGRP-2245:
---------------------------------
Description:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) because of the crashed members non existing ip address
sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
> Key: JGRP-2245
> URL: https://issues.jboss.org/browse/JGRP-2245
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.8
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> // remove all files which are not from the current members
> protected void handleView(View new_view, View old_view, boolean coord_changed) {
> if(is_coord) {
> if(coord_changed) {
> if(remove_all_data_on_view_change)
> removeAll(cluster_name);
> else if(remove_old_coords_on_view_change) {
> Address old_coord=old_view != null? old_view.getCreator() : null;
> if(old_coord != null)
> remove(cluster_name, old_coord);
> }
> }
> if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
> writeAll();
> if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
> startInfoWriter();
> }
> }
> else if(coord_changed) // I'm no longer the coordinator
> remove(cluster_name, local_addr);
> }
> 4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar updated JGRP-2245:
---------------------------------
Description:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.
was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
> Key: JGRP-2245
> URL: https://issues.jboss.org/browse/JGRP-2245
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.8
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> // remove all files which are not from the current members
> protected void handleView(View new_view, View old_view, boolean coord_changed) {
> if(is_coord) {
> if(coord_changed) {
> if(remove_all_data_on_view_change)
> removeAll(cluster_name);
> else if(remove_old_coords_on_view_change) {
> Address old_coord=old_view != null? old_view.getCreator() : null;
> if(old_coord != null)
> remove(cluster_name, old_coord);
> }
> }
> if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
> writeAll();
> if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
> startInfoWriter();
> }
> }
> else if(coord_changed) // I'm no longer the coordinator
> remove(cluster_name, local_addr);
> }
> 4) Because of the crashed members (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar updated JGRP-2245:
---------------------------------
Description:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) because of the crashed members non existing ip address
sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused when other nodes restarts.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
I think the issue is
handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
// remove all files which are not from the current members
protected void handleView(View new_view, View old_view, boolean coord_changed) {
if(is_coord) {
if(coord_changed) {
if(remove_all_data_on_view_change)
removeAll(cluster_name);
else if(remove_old_coords_on_view_change) {
Address old_coord=old_view != null? old_view.getCreator() : null;
if(old_coord != null)
remove(cluster_name, old_coord);
}
}
if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
writeAll();
if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
startInfoWriter();
}
}
else if(coord_changed) // I'm no longer the coordinator
remove(cluster_name, local_addr);
}
4) because of the crashed members non existing ip address
sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
> Key: JGRP-2245
> URL: https://issues.jboss.org/browse/JGRP-2245
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.8
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> // remove all files which are not from the current members
> protected void handleView(View new_view, View old_view, boolean coord_changed) {
> if(is_coord) {
> if(coord_changed) {
> if(remove_all_data_on_view_change)
> removeAll(cluster_name);
> else if(remove_old_coords_on_view_change) {
> Address old_coord=old_view != null? old_view.getCreator() : null;
> if(old_coord != null)
> remove(cluster_name, old_coord);
> }
> }
> if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
> writeAll();
> if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
> startInfoWriter();
> }
> }
> else if(coord_changed) // I'm no longer the coordinator
> remove(cluster_name, local_addr);
> }
> 4) because of the crashed members non existing ip address
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months