[JBoss JIRA] (WFLY-9586) Persistent EJB timers should resume only once if missed multiple times
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-9586:
--------------------------------------
Summary: Persistent EJB timers should resume only once if missed multiple times
Key: WFLY-9586
URL: https://issues.jboss.org/browse/WFLY-9586
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Wolf-Dieter Fink
Timers which are persistent need to resume if the timeout is missed, i.e. if the server was down.
The EJB specification say by §13.2:
"In the event of a container crash or container shutdown, the timeout callback method for a persistent timer that has not been cancelled will be invoked on a new JVM when the container is restarted or on another JVM instance across which the container is distributed. This rule applies to both programmatically or automatically created persistent timers."
The understanding is not clear and can be
- resume ALL missed timeouts
- resume but fire the timer only once
As Wildfly prevent from having the same timeout running concurrent a server start will have the effect that multiple timeouts are fired (assume you have a timer scheduled for every second and the server is down for minutes) but only the first (or a couple) will efectively executed all other will 'only' burden the server and log warn/error messages.
The effect for the server start is a slower startup, long list of log messages and no real benefit!
If the spec is really unclear here a configuration flag should be added to control that behaviour (like done for ejb invocation in-vm calls - byReference/byValue)
The current behaviour should be the default but a boolean attribute should allow to fire the timer only once and set the next timeout according to the schedule (recurring or calendar) in the future.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
Shing Lam created WFLY-9585:
-------------------------------
Summary: Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
Key: WFLY-9585
URL: https://issues.jboss.org/browse/WFLY-9585
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
Reporter: Shing Lam
We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
We have in the ejb-jar.xml
{code:xml}
<enterprise-beans>
<session>
<ejb-name>BackgroundRecoverySessionEJB</ejb-name>
<resource-ref>
<res-ref-name>jdbc/RMDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<persistence-context-ref>
<persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
</persistence-context-ref>
</session>
{code}
and in jboss-ejb3.xml
{code:xml}
<jboss:enterprise-beans>
<jboss:ejb>
<ejb-name>BackgroundRecoverySessionEJB</ejb-name>
<resource-ref>
<res-ref-name>jdbc/RMDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
</resource-ref>
</jboss:ejb>
{code}
the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3439?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3439:
-------------------------------------
Description:
DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation.
Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation.
One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input.
As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that.
was:
DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation.
Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation.
One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input.
As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that.
> Reevaluate MultiphaseOverallContext.transformServerOperation
> ------------------------------------------------------------
>
> Key: WFCORE-3439
> URL: https://issues.jboss.org/browse/WFCORE-3439
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation.
> Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation.
> One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input.
> As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3439:
----------------------------------------
Summary: Reevaluate MultiphaseOverallContext.transformServerOperation
Key: WFCORE-3439
URL: https://issues.jboss.org/browse/WFCORE-3439
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation.
Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation.
One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input.
As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (LOGMGR-183) Java 7+ level hack on the LogManager does not work
by James Perkins (JIRA)
James Perkins created LOGMGR-183:
------------------------------------
Summary: Java 7+ level hack on the LogManager does not work
Key: LOGMGR-183
URL: https://issues.jboss.org/browse/LOGMGR-183
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The {{org.jboss.logmanager.LogManager}} uses {{getConstructor()}} method for the {{java.util.logging.Level$KnownLevel}} hack. This should be using {{getDeclaredConstructor()}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (JBJCA-1361) Documentation for flush strategies needs clarification
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1361?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1361:
---------------------------------
Description:
http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html...
It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense.
The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections - specifically to those that are associated with a specific authentication credential whereas the {{All*}} variants include all subsets associated with the datasource (regardless of credentials).
was:
http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html...
It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense.
The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections that are associated with a specific authentication credential whereas the {{All*}} variants are not so limited.
> Documentation for flush strategies needs clarification
> ------------------------------------------------------
>
> Key: JBJCA-1361
> URL: https://issues.jboss.org/browse/JBJCA-1361
> Project: IronJacamar
> Issue Type: Bug
> Components: Documentation
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: Stephen Fikes
>
> http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html...
> It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense.
> The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections - specifically to those that are associated with a specific authentication credential whereas the {{All*}} variants include all subsets associated with the datasource (regardless of credentials).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (JBJCA-1361) Documentation for flush strategies needs clarification
by Stephen Fikes (JIRA)
Stephen Fikes created JBJCA-1361:
------------------------------------
Summary: Documentation for flush strategies needs clarification
Key: JBJCA-1361
URL: https://issues.jboss.org/browse/JBJCA-1361
Project: IronJacamar
Issue Type: Bug
Components: Documentation
Affects Versions: 1.2.7.Final, WildFly/IronJacamar 1.3.4.Final
Reporter: Stephen Fikes
http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html...
It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense.
The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections that are associated with a specific authentication credential whereas the {{All*}} variants are not so limited.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9584) Adding protocol with override definition to fork results in IllegalStateException
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-9584:
----------------------------------
Summary: Adding protocol with override definition to fork results in IllegalStateException
Key: WFLY-9584
URL: https://issues.jboss.org/browse/WFLY-9584
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Paul Ferraro
Assignee: Paul Ferraro
{noformat}
[standalone@embedded /] /subsystem=jgroups/channel=ee/fork=foo/protocol=MPING:add(socket-binding=http)
14:46:40,228 ERROR [org.jboss.as.controller.management-operation] (pool-4-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "jgroups"),
("channel" => "ee"),
("fork" => "foo"),
("protocol" => "MPING")
]): java.lang.IllegalStateException: WFLYCTL0221: An override model registration is not allowed for non-wildcard model registrations. This registration is for the non-wildcard name 'MPING'.
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerOverrideModel(AbstractResourceRegistration.java:122)
at org.jboss.as.clustering.jgroups.subsystem.ForkProtocolRuntimeResourceRegistration.register(ForkProtocolRuntimeResourceRegistration.java:127)
at org.jboss.as.clustering.controller.AddStepHandler.lambda$null$2(AddStepHandler.java:117)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient$1$1.lambda$run$0(ModelControllerClientFactoryImpl.java:170)
at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:63)
at org.jboss.as.controller.SecurityActions$InVmActions$1.runInVm(SecurityActions.java:149)
at org.jboss.as.controller.SecurityActions.runInVm(SecurityActions.java:49)
at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient$1$1.run(ModelControllerClientFactoryImpl.java:170)
at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient$1$1.run(ModelControllerClientFactoryImpl.java:163)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:198)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:175)
at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient$1.run(ModelControllerClientFactoryImpl.java:163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0221: An override model registration is not allowed for non-wildcard model registrations. This registration is for the non-wildcard name 'MPING'.",
"rolled-back" => true
}
{noformat}
Normally, protocols register a runtime resource that exposes its properties as runtime attribute to the management model. This is implemented by registering an override model at runtime. However, if the protocol already uses an override model, the registration will fail.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months