[JBoss JIRA] (WFLY-5613) Fix transaction subsystem resource descriptions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5613?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5613:
--------------------------------
Fix Version/s: 10.0.0.Final
(was: 11.0.0.CR1)
> 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
> Priority: Minor
> Fix For: 10.0.0.Final
>
> 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)
9 years, 9 months
[JBoss JIRA] (DROOLS-1021) Add method on KieContainer to get the KieBase for an ksessionName (without instantiating the KieSession)
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1021:
----------------------------------------
Summary: Add method on KieContainer to get the KieBase for an ksessionName (without instantiating the KieSession)
Key: DROOLS-1021
URL: https://issues.jboss.org/browse/DROOLS-1021
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
OptaPlanner is switching from using KieBase (with a drl classpath resource to retrieve the rules) to KContainer (with ksessionName to retrieve the rules), so it can function as part of a kjar.
During bootstrap, it needs to check the rules if a specific Global is defined.
Currently *it needs to instantiate a throwaway KieSession* to do that which is bad:
{code}
KieSession kieSession = kieContainer.newKieSession(ksessionName); // BAD
KieBase kieBase = kieSession.getKieBase();
checkIfGlobalScoreHolderExists(kieBase);
{code}
It would be much nicer if we could do this instead:
{code}
KieBase kieBase = kieContainer.getKieBaseForKsessionName(ksessionName);
checkIfGlobalScoreHolderExists(kieBase);
{code}
So the proposal is to add that new method kieContainer.getKieBaseForKsessionName(String ksessionName)
For the record, here's that check method that's being called at bootstrap:
{code}
protected void checkIfGlobalScoreHolderExists(KieBase kieBase) {
boolean hasGlobalScoreHolder = false;
for (KiePackage kiePackage : kieBase.getKiePackages()) {
for (Global global : kiePackage.getGlobalVariables()) {
if (DroolsScoreDirector.GLOBAL_SCORE_HOLDER_KEY.equals(global.getName())) {
hasGlobalScoreHolder = true;
break;
}
}
}
if (!hasGlobalScoreHolder) {
throw new IllegalArgumentException("The kieBase with kiePackages (" + kieBase.getKiePackages()
+ ") has no global field called " + DroolsScoreDirector.GLOBAL_SCORE_HOLDER_KEY + ".\n"
+ "Check if the rule files are found and if the global field is spelled correctly.");
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-383) Update ServerAuthenticationContext to carry an identity from start to end
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-383?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-383.
-----------------------------
Resolution: Done
> Update ServerAuthenticationContext to carry an identity from start to end
> -------------------------------------------------------------------------
>
> Key: ELY-383
> URL: https://issues.jboss.org/browse/ELY-383
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta4
>
> Attachments: Blank Flowchart - ServerAuthenticationContext.png
>
>
> The {{ServerAuthenticationContext}} should capture the identity in force for its domain when it is constructed. Any authorization attempt should always apply to the current identity - either the captured identity, or whatever the last successfully authorized identity was in the context.
> The attached state diagram should accurately summarize how authorization identity flows through. Authentication identity is only available during the "NAME ASSIGNED" state; once authorization occurs, the authentication identity is no longer useful and is disposed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1272) Clean the deployment Resource in RootDeploymentUnitService's stop() method
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1272:
----------------------------------------
Summary: Clean the deployment Resource in RootDeploymentUnitService's stop() method
Key: WFCORE-1272
URL: https://issues.jboss.org/browse/WFCORE-1272
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, Server
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
DUPs can modify the Resource associated with a deployment in their deploy method, and should, by the DUP contract, reverse that change in undeploy. Scott's WFLY-4908 fix does this, and is good as it means the behavior is correct per the DUP contract.
But as a second line of defense, RootDeploymentUnitService's stop method can clean up the deployment resource using DeploymentResourceSupport.cleanup. This will ensure that if the service is stopped by MSC without an undeploy or redeploy mgmt op being involved, if the service is started again the deployment resource will be back in the state it was when the RDUS was first constructed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1269) Resource passed into RootDeploymentUnitService is decoupled from official model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1269?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1269.
--------------------------------------
Resolution: Won't Do
I've decided not to try and fix this, at least not via keeping this resource in sync.
The problem is for this to work properly, the resource cached in the DeploymentUnit would have to have visibility to unpublished changes being made by subsequently executing ops, not just to the changes made once the subsequent op commits. And making that change would be too problematic
For example, in the WFLY-4908 case an undeploy op affecting deployment 1 is triggering MSC to stop services for deployment 2, and then a later deploy op for deployment one causes MSC to start the services for deployment 2. Neither the undeploy or deploy ops directly relate to deployment 2. But because of the MSC dependency, the deployment 2 DUPs run during both. But the DUP don't have a ref to the currently unpublished resource tree used by those ops.
I'm closing this and am going to open a different issue for a minor change to help avoid the need for things like Scott's WFLY-4908 fix.
> Resource passed into RootDeploymentUnitService is decoupled from official model
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1269
> URL: https://issues.jboss.org/browse/WFCORE-1269
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Server
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
>
> When DeploymentHandlerUtil.doDeploy passes the Resource for the deployment into RootDeploymentUnitService, it is from the currently executing management ops version of the resource tree, and becomes the "official" version once that op commits. But once another config write op commits, the Resource instance cached by the RootDeploymentUnitService and attached by it to the DeplopymentUnit is no longer the official copy; it's a previous copy, aka "cruft". So any mutation to it is not affecting the official copy.
> Where this can be an issue is if the deployment services stop or restart due to MSC dependency changes (i.e. some service depended upon by the deployment stops or restarts), but not due to deploy/undeploy/redeploy ops affecting the deployment directly. The stop/restart will trigger the DUPs which then may attempt the out of date "cruft" Resource.
> WFLY-4908 is an example of such modification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1982 at 1/6/16 10:07 AM:
---------------------------------------------------------
Hmm, we could check whether we find a contiguous amount of free space, and do compaction, e.g.
||0||1||2||3||4||5||6||7||
|0|-|-|-|-|-|-|7|
Here we have an array of capacity=8, with request IDs 0 (at index 0) and 7 (at index 7). We have 6 free array slots available for compaction. We could therefore compact the array to (say) 4 (or even 2):
||0||1||2||3||
|0|-|-|7|
0 mod 4 is index=0 and 7 mod 4 is index=3, so this works as long as we find half of the buffer size more free slots.
The question is _when_ to check if the array can be compacted and determining the minimum number of free slots for compaction...
was (Author: belaban):
Hmm, we could check whether we find a contiguous amount of free space, and do compaction, e.g.
||0||1||2||3||4||5||6||7||
|0|-|-|-|-|-|-|7|
Here we have an array of capacity=8, with request IDs 0 (at index 0) and 7 (at index 7). We have 6 free array slots available for compaction. We could therefore compact the array to (say) 4 (or even 2):
||0||1||2||3||
|0|-|-|7|
0 mod 4 is index=0 and 7 mod 4 is index=3, so this works.
The question is _when_ to check if the array can be compacted and determining the minimum number of free slots for compaction...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-401) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-401:
------------------------------------
Summary: ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
Key: ELY-401
URL: https://issues.jboss.org/browse/ELY-401
Project: WildFly Elytron
Issue Type: Bug
Components: SSL, Utils
Reporter: Darran Lofthouse
Fix For: 1.1.0.Beta4
Getting the following warning logged when filtering the ciphers available from Oracle Java 8 with unlimited strength policy files in place: -
{noformat}
ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA"
{noformat}
_The JCE policy is probably unrelated, mentioning it just in case._
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months