[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1977?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1977:
---------------------------
Fix Version/s: 3.6.7
I'll take a look. I don't want to change this logic though as GMS should not know what kind of transport is present (TCP or UDP).
If a change is needed, this should rather be in {{PING}} or {{UDP}} itself.
> More redundant initial join logic to avoid becoming a fake coordinator
> ----------------------------------------------------------------------
>
> Key: JGRP-1977
> URL: https://issues.jboss.org/browse/JGRP-1977
> Project: JGroups
> Issue Type: Bug
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes.
> This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable.
> Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5613) Fix transaction subsystem resource descriptions
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5613?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5613:
----------------------------------------
[~zhfeng] I've checked the PR and I like the changes. Thank you. I've added only one comment where I would like to ask for change. In description of statistics would be better to omit information taken from web console.
> Fix transaction subsystem resource descriptions
> -----------------------------------------------
>
> Key: WFLY-5613
> URL: https://issues.jboss.org/browse/WFLY-5613
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Attachments: jts-tooltip-700.DR132.png
>
>
> I would like ask for changing text in transaction configuration helper tooltip (_Need Help?
> _). First there is an issue of not having an information that jts to be fully enabled is need to set subsystem of iiop orb as well (the same issue was for 6.4.0 https://bugzilla.redhat.com/show_bug.cgi?id=995439).
> Nevertheless I would like ask for a bit more general change of the text in the help webconsole tooltip
> Current text is
> {noformat}
> Default timeout: The default timeout.
> Enable tsm status: Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not..
> Journal store enable async io: Whether AsyncIO should be enabled for the journal store. Default is false. The server should be restarted for this setting to take effect.
> Jts: If true this enables the Java Transaction Service.
> Node identifier: Used to set the node identifier on the core environment.
> Statistics enabled: Whether statistics should be enabled.
> Use journal store: Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to jdbc based store.
> {noformat}
> {noformat}
> Process id uuid: Indicates whether the transaction manager should use a UUID based process id.
> Process id socket binding: The name of the socket binding configuration to use if the transaction manager should use a socket-based process id. Will be 'undefined' if 'process-id-uuid' is 'true'; otherwise must be set.
> Process id socket max ports: The maximum number of ports to search for an open port if the transaction manager should use a socket-based process id. If the port specified by the socket binding referenced in 'process-id-socket-binding' is occupied, the next higher port will be tried until an open port is found or the number of ports specified by this attribute have been tried. Will be 'undefined' if 'process-id-uuid' is 'true'.
> {noformat}
> {noformat}
> Socket binding: Used to reference the correct socket binding to use for the recovery environment.
> Status socket binding: Used to reference the correct socket binding to use for the transaction status manager.
> Recovery listener: Used to specify if the recovery system should listen on a network socket or not.
> {noformat}
> {noformat}
> Object store path: Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute.
> Object store relative to: References a global path configuration in the domain model, defaulting to the JBoss Application Server data directory (jboss.server.data.dir). The value of the "path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "path" attribute to be treated as an absolute path.
> {noformat}
> {noformat}
> Use jdbc store: Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to Horneq based store
> Jdbc action store drop table: Configure if jdbc action store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc action store table prefix: Optional prefix for table used to write transcation logs in configured jdbc action store. The server should be restarted for this setting to take effect.
> Jdbc communication store drop table: Configure if jdbc communication store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc communication store table prefix: Optional prefix for table used to write transcation logs in configured jdbc communication store. The server should be restarted for this setting to take effect.
> Jdbc state store drop table: Configure if jdbc state store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc state store table prefix: Optional prefix for table used to write transcation logs in configured jdbc state store. The server should be restarted for this setting to take effect.
> Jdbc store datasource: Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. The server should be restarted for this setting to take effect.
> {noformat}
> I would propose the following changes in the tooltip text
> *Attributes*
> * Default timeout
> ** The default timeout for a transaction managed by the transaction manager.
> * Enable tsm status
> ** Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not.
> * Journal store enable async io
> ** Whether AsyncIO should be enabled for the journal store. Default is false. For this settings being active journal natives libraries needs to be available. The server should be restarted for this setting to take effect.
> * Jts
> ** If true this enables the Java Transaction Service. Use of the JTS needs configuration in IIOP OpenJDK where Transactions parameter needs to be set to full. The server should be restarted for this setting to take effect.
> * Node identifier
> ** Used to set the node identifier on the core environment. Each server should have this identifier unique. It's an identifier which differentiates XA transactions as created by this node. The server should be restarted for this setting to take effect.
> * Statistics enabled
> ** Whether transaction statistics should be enabled. The transaction statistics could be seen in section Runtime > Monitor > Subsystems > Transactions. The server should be reloaded for this setting to take effect.
> * Use journal store
> ** Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store. The server should be restarted for this setting to take effect.
> *Process ID* + *Recovery*
> Add information that for settings these attributes taking effect the server needs to be reloaded.
> *Path*
> * Object store path
> ** Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute. This settings is valid when default or journal store is used. It's not used when jdbc journal store is used. The server should be reloaded for this setting to take effect.
> * Object store relative to
> ** References a global path configuration in the domain model, defaulting to the Application Server data directory (jboss.server.data.dir). The value of the "Object store path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "Object store path" attribute to be treated as an absolute path. The server should be reloaded for this setting to take effect.
> *JDBC*
> * Use jdbc store
> ** Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store. The server should be restarted for this setting to take effect.
> * Jdbc store datasource
> ** Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. For this would work the non-XA datasource has to be marked as jta="false". The server should be restarted for this setting to take effect.
> ...the rest of the information is ok from my point of view
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1976) Choose the next coordinator from the largest sub-cluster when merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1976?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1976:
---------------------------
Fix Version/s: 3.6.7
This makes sense. I'll make LargestWinningPolicy the new default policy.
Thanks!
> Choose the next coordinator from the largest sub-cluster when merge
> -------------------------------------------------------------------
>
> Key: JGRP-1976
> URL: https://issues.jboss.org/browse/JGRP-1976
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.7
>
> Attachments: LargestWinningPolicy.java
>
>
> When sub-clusters merge, the current DefaultMembershipPolicy collects all coordinators from the sub-clusters and sorts it, then chooses the first one as the next coordinator (JGRP-1002). The sort is done by UUID which is random. Please consider to change the algorithm slightly to choose the one from the largest (in terms of the number of members) sub-cluster and make it the default.
> Choosing the largest one is reasonable from many point of views. For example, a WildFly cluster hosting a singleton service becomes more robust. Another scenario is about a large Inifnispan cluster. When you add an extra node and the node resides into another network segment, the new node tends to become an isolated coordinator initially (because a switch requires some time to reflect a new multicast route between the segments) then merges later. With the current implementation, this new node becomes the coordinator frequently and affects stability of the cluster by a cluster-wide rebalance. This is bad because the intention is to ease the cluster, not to unstabilize it.
> The implementation can be customized by membership_change_policy property of pbcast.GMS. I attach my implementation as LargestWinningPolicy.java as a reference.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator
by Osamu Nagano (JIRA)
Osamu Nagano created JGRP-1977:
----------------------------------
Summary: More redundant initial join logic to avoid becoming a fake coordinator
Key: JGRP-1977
URL: https://issues.jboss.org/browse/JGRP-1977
Project: JGroups
Issue Type: Bug
Reporter: Osamu Nagano
Assignee: Bela Ban
If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes.
This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable.
Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1976) Choose the next coordinator from the largest sub-cluster when merge
by Osamu Nagano (JIRA)
Osamu Nagano created JGRP-1976:
----------------------------------
Summary: Choose the next coordinator from the largest sub-cluster when merge
Key: JGRP-1976
URL: https://issues.jboss.org/browse/JGRP-1976
Project: JGroups
Issue Type: Enhancement
Reporter: Osamu Nagano
Assignee: Bela Ban
Attachments: LargestWinningPolicy.java
When sub-clusters merge, the current DefaultMembershipPolicy collects all coordinators from the sub-clusters and sorts it, then chooses the first one as the next coordinator (JGRP-1002). The sort is done by UUID which is random. Please consider to change the algorithm slightly to choose the one from the largest (in terms of the number of members) sub-cluster and make it the default.
Choosing the largest one is reasonable from many point of views. For example, a WildFly cluster hosting a singleton service becomes more robust. Another scenario is about a large Inifnispan cluster. When you add an extra node and the node resides into another network segment, the new node tends to become an isolated coordinator initially (because a switch requires some time to reflect a new multicast route between the segments) then merges later. With the current implementation, this new node becomes the coordinator frequently and affects stability of the cluster by a cluster-wide rebalance. This is bad because the intention is to ease the cluster, not to unstabilize it.
The implementation can be customized by membership_change_policy property of pbcast.GMS. I attach my implementation as LargestWinningPolicy.java as a reference.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5613) Fix transaction subsystem resource descriptions
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5613?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-5613:
---------------------------------
[~ochaloup] I just send the PR https://github.com/wildfly/wildfly/pull/8387 and can you take a look at it ?
> Fix transaction subsystem resource descriptions
> -----------------------------------------------
>
> Key: WFLY-5613
> URL: https://issues.jboss.org/browse/WFLY-5613
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Attachments: jts-tooltip-700.DR132.png
>
>
> I would like ask for changing text in transaction configuration helper tooltip (_Need Help?
> _). First there is an issue of not having an information that jts to be fully enabled is need to set subsystem of iiop orb as well (the same issue was for 6.4.0 https://bugzilla.redhat.com/show_bug.cgi?id=995439).
> Nevertheless I would like ask for a bit more general change of the text in the help webconsole tooltip
> Current text is
> {noformat}
> Default timeout: The default timeout.
> Enable tsm status: Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not..
> Journal store enable async io: Whether AsyncIO should be enabled for the journal store. Default is false. The server should be restarted for this setting to take effect.
> Jts: If true this enables the Java Transaction Service.
> Node identifier: Used to set the node identifier on the core environment.
> Statistics enabled: Whether statistics should be enabled.
> Use journal store: Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to jdbc based store.
> {noformat}
> {noformat}
> Process id uuid: Indicates whether the transaction manager should use a UUID based process id.
> Process id socket binding: The name of the socket binding configuration to use if the transaction manager should use a socket-based process id. Will be 'undefined' if 'process-id-uuid' is 'true'; otherwise must be set.
> Process id socket max ports: The maximum number of ports to search for an open port if the transaction manager should use a socket-based process id. If the port specified by the socket binding referenced in 'process-id-socket-binding' is occupied, the next higher port will be tried until an open port is found or the number of ports specified by this attribute have been tried. Will be 'undefined' if 'process-id-uuid' is 'true'.
> {noformat}
> {noformat}
> Socket binding: Used to reference the correct socket binding to use for the recovery environment.
> Status socket binding: Used to reference the correct socket binding to use for the transaction status manager.
> Recovery listener: Used to specify if the recovery system should listen on a network socket or not.
> {noformat}
> {noformat}
> Object store path: Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute.
> Object store relative to: References a global path configuration in the domain model, defaulting to the JBoss Application Server data directory (jboss.server.data.dir). The value of the "path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "path" attribute to be treated as an absolute path.
> {noformat}
> {noformat}
> Use jdbc store: Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file system file per transaction log. The server should be restarted for this setting to take effect. It's alternative to Horneq based store
> Jdbc action store drop table: Configure if jdbc action store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc action store table prefix: Optional prefix for table used to write transcation logs in configured jdbc action store. The server should be restarted for this setting to take effect.
> Jdbc communication store drop table: Configure if jdbc communication store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc communication store table prefix: Optional prefix for table used to write transcation logs in configured jdbc communication store. The server should be restarted for this setting to take effect.
> Jdbc state store drop table: Configure if jdbc state store should drop tables. Default is false. The server should be restarted for this setting to take effect.
> Jdbc state store table prefix: Optional prefix for table used to write transcation logs in configured jdbc state store. The server should be restarted for this setting to take effect.
> Jdbc store datasource: Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. The server should be restarted for this setting to take effect.
> {noformat}
> I would propose the following changes in the tooltip text
> *Attributes*
> * Default timeout
> ** The default timeout for a transaction managed by the transaction manager.
> * Enable tsm status
> ** Whether the transaction status manager (TSM) service, needed for out of process recovery, should be provided or not.
> * Journal store enable async io
> ** Whether AsyncIO should be enabled for the journal store. Default is false. For this settings being active journal natives libraries needs to be available. The server should be restarted for this setting to take effect.
> * Jts
> ** If true this enables the Java Transaction Service. Use of the JTS needs configuration in IIOP OpenJDK where Transactions parameter needs to be set to full. The server should be restarted for this setting to take effect.
> * Node identifier
> ** Used to set the node identifier on the core environment. Each server should have this identifier unique. It's an identifier which differentiates XA transactions as created by this node. The server should be restarted for this setting to take effect.
> * Statistics enabled
> ** Whether transaction statistics should be enabled. The transaction statistics could be seen in section Runtime > Monitor > Subsystems > Transactions. The server should be reloaded for this setting to take effect.
> * Use journal store
> ** Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store. The server should be restarted for this setting to take effect.
> *Process ID* + *Recovery*
> Add information that for settings these attributes taking effect the server needs to be reloaded.
> *Path*
> * Object store path
> ** Denotes a relative or absolute filesystem path denoting where the transaction manager object store should store data. By default the value is treated as relative to the path denoted by the "relative-to" attribute. This settings is valid when default or journal store is used. It's not used when jdbc journal store is used. The server should be reloaded for this setting to take effect.
> * Object store relative to
> ** References a global path configuration in the domain model, defaulting to the Application Server data directory (jboss.server.data.dir). The value of the "Object store path" attribute will treated as relative to this path. Use an empty string to disable the default behavior and force the value of the "Object store path" attribute to be treated as an absolute path. The server should be reloaded for this setting to take effect.
> *JDBC*
> * Use jdbc store
> ** Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store. The server should be restarted for this setting to take effect.
> * Jdbc store datasource
> ** Jndi name of non-XA datasource used. Datasource sghould be define in datasources subsystem. For this would work the non-XA datasource has to be marked as jta="false". The server should be restarted for this setting to take effect.
> ...the rest of the information is ok from my point of view
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBJCA-1276) Prefill race condition in flush
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1276?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1276:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1231658|https://bugzilla.redhat.com/show_bug.cgi?id=1231658] from MODIFIED to ON_QA
> Prefill race condition in flush
> -------------------------------
>
> Key: JBJCA-1276
> URL: https://issues.jboss.org/browse/JBJCA-1276
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.31.Final, 1.1.9.Final
> Reporter: Takayoshi Kimura
> Assignee: Jesper Pedersen
> Fix For: 1.0.33.Final
>
> Attachments: server.log
>
>
> There is a race condition between AbstractPool and SemaphoreArrayListManagedConnectionPool.
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> AbstractPool flushes the mcp, mcp invokes PoolFiller which works in a separate thread. However AbstractPool is going to unregister the empty mcp and this mcp is no longer used. Then the dead mcp is prefilled in a separate thread by PoolFiller.
> At next getConnection(), the mcp is re-initialized and prefilled.
> I've attached logs, prefill enabled and min-size is 10. Boot server, invoke flush-all-connection-in-pool, getConnection() then killed. The prefill is done 3 times where it should be twice.
> {noformat}
> 16:26:04,254 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) ExampleDS: flush(true)
> 16:26:04,255 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) Destroying flushed connection org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1d298ed8[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@4ae26a1b connection handles=0 lastUse=1434353148384 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@379ba3b3[connectionListener=1d298ed8 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:02:20,666 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 7) Shutdown - Pool: ExampleDS MCP: 2f5a2102
> 16:02:20,666 TRACE [org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory] (JCA PoolFiller) Using properties: {user=sa, password=--hidden--}
> 16:02:20,666 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (management-handler-thread - 7) Unregister pool: SemaphoreArrayListManagedConnectionPool@2f5a2102[pool=ExampleDS]
> 16:26:04,259 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@34f0bb27[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@288f1898 connection handles=0 lastUse=1434353164259 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@4a97b7f5[connectionListener=34f0bb27 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:26:11,342 TRACE [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http-/127.0.0.1:8080-1) getManagedConnection interleaving=false , tx=null
> 16:26:11,343 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (http-/127.0.0.1:8080-1) Register pool: SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] (interval=1800000)
> 16:26:11,344 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1c706b4d[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@18949ad1 connection handles=0 lastUse=1434353171343 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] xaResource=LocalXAResourceImpl@44401bf2[connectionListener=1c706b4d connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> {noformat}
> In 1.0.31.Final:
> > if (mcp.isEmpty())
> > clearMcpPools.add(mcp);
> In 1.2 branch it looks like already fixed within commit 956af09c8494d4187db24a253e7e37b5ba5d9779 for JBJCA-1135:
> > if (mcp.isEmpty() && !isPrefill() && size > 1)
> > clearMcpPools.add(mcp);
> We probably need to backport "!isPrefill()" to the 1.0/1.1 branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-979) ignore-unused-configuration default value change testsuite changes.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-979:
------------------------------------
Component/s: Domain Management
Test Suite
> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
> Key: WFCORE-979
> URL: https://issues.jboss.org/browse/WFCORE-979
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Test Suite
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
> testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >
> > <domain-controller>
> > <!-- Remote domain controller configuration with a host and port -->
> > - <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > + <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-918) Allow embedded server logging to be overridden by properties
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-918?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-918:
------------------------------------
Component/s: CLI
> Allow embedded server logging to be overridden by properties
> ------------------------------------------------------------
>
> Key: WFCORE-918
> URL: https://issues.jboss.org/browse/WFCORE-918
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> For example:
> $ export JBOSS_HOME=/home/kwills/git/wildfly/build/target/wf/
> $ java -jar wildfly-10.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar -Djboss.server.base.dir=standalone1 -Djboss.server.log.dir=log
> [disconnected /] embed-server --std-out=echo
> This should log to $JBOSS_HOME/standalone1/log
> The properties available to override are:
> jboss.server.base.dir defaults to jbossHome.getAbsolutePath() + File.separator + "standalone" ("domain" for domain servers).
> jboss.server.configuration.dir defaults to "configuration"
> jboss.server.log.dir defaults to log
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months