[JBoss JIRA] (WFCORE-1456) org.jboss.as.cli.scriptsupport.CLI prevents use of embed-server and embed-host-controller
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1456?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-1456:
--------------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1495
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> org.jboss.as.cli.scriptsupport.CLI prevents use of embed-server and embed-host-controller
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1456
> URL: https://issues.jboss.org/browse/WFCORE-1456
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Jean-Francois Denise
>
> The org.jboss.as.cli.scriptsupport.CLI will throw an exception if the user invokes the cmd method before invoking one of the connect methods. But the connect/disconnect methods are oriented toward remote connections. The result is you can't really use this class with the offline CLI.
> I'm not sure what the best fix is here. Perhaps new method(s) analogous to connect/disconnect that establish a CommandContext but don't call connectController(). Or perhaps the checkNotConnected() call in the cmd method should just be dropped, and an unconnected command context created. But then the existing connect/disconnect methods would need to be reworked to deal with the fact that an unconnected command context may be present.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6294:
---------------------------------
Bugzilla Update: (was: Perform)
> Session draining always takes maximum configured timeout
> --------------------------------------------------------
>
> Key: WFLY-6294
> URL: https://issues.jboss.org/browse/WFLY-6294
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Radoslav Husar
> Priority: Minor
>
> The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
> {code}
> while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
> ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
> listener.wait(noTimeout ? 0 : timeout);
> current = System.currentTimeMillis();
> timeout = end - current;
> remainingSessions = context.getActiveSessionCount();
> }
> {code}
> Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6417) ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6417?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6417:
-------------------------------------------
This was my proposed fix: https://github.com/rachmatowicz/jboss-ejb-client/tree/WFLY-6417
Still snowed under with other stuff at the moment.
> ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6417
> URL: https://issues.jboss.org/browse/WFLY-6417
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Richard Achmatowicz
>
> I have tests that start 2 clusters and a standalone EJB client and do remote EJB invocations like this: standalone EJB client -> cluster 1 (forwarder) -> cluster 2 (target) -> back to cluster 1 -> back to standalone client.
> During a graceful shutdown variant of such tests, where the nodes of the clusters are repeatedly shut down and then brough back up to life, one node at a time, I've seen an {{ArrayIndexOutOfBoundsException}} in EJB client on one of the forwarder nodes:
> {code}
> 2016-03-21 14:26:59,050 ERROR [org.jboss.as.ejb3.invocation] (default task-110) WFLYEJB0034: EJB Invocation failed on component ForwardingBeanImpl for method public abstract java.lang.String org.jboss.qa.eap.clustering.[redacted].testApps.june2013.Bean.test(java.lang.String,long): javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException: 5
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy63.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].testApps.june2013.ForwardingBeanImpl.test(ForwardingBeanImpl.java:30)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 44 more
> {code}
> In the log, this exception is preceded by warnings about failed invocations and "No EJBReceiver available" which I don't understand -- at the time, all nodes should be up and running and seeing each other (which seems to be confirmed by the logs).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-102:
------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from ASSIGNED to POST
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1471) Side effect in CommandContext instances when connection to server is failing
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1471:
--------------------------------------------
Summary: Side effect in CommandContext instances when connection to server is failing
Key: WFCORE-1471
URL: https://issues.jboss.org/browse/WFCORE-1471
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Alpha1
Reporter: Jean-Francois Denise
Assignee: Alexey Loubyansky
Creating and connecting a context although the remote server is not yet up and running has a side effect in this following case:
1) Create a fresh context
2) Embed a server
3) Reload it with management enabled
4) Create another Context and connect to embedded remote interface
==> All is fine
Add a step in between 1) an 2) the create and connect a context to the remote management interface (that obviously is not yet there) and step 3) will fail. Reloading the embedded server fails
The way to reload the embedded server has an impact. context.handle(...) will not be affected, context.getControllerClient().execute(...) is impacted.. So something wrong there to chase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1120) KieModuleMetaData.getProcess() ignores processes defined in file with extension bpmn
by Maciej Swiderski (JIRA)
Maciej Swiderski created DROOLS-1120:
----------------------------------------
Summary: KieModuleMetaData.getProcess() ignores processes defined in file with extension bpmn
Key: DROOLS-1120
URL: https://issues.jboss.org/browse/DROOLS-1120
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.CR2
Reporter: Maciej Swiderski
Assignee: Mario Fusco
KieModuleMetaData.getProcesses() takes into consideration only files with extension bpmn2 while valid extension (and frequently used one) is bpmn. Thus both extensions should be considered as valid process file and by that added to map of processes collected by KieModuleMetaData
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1157) Managmement and JMX notifications when ControlledProcessState changes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1157:
------------------------------------------
I think it's ok to use a listener on ControlledProcessState to trigger sending the management notification.
I think hardcoding the starting notification is fine. Sending it at all is a bit silly as there can't be any kernel management listeners at that point. I suppose there could be a JMX listener of some type. I'm not sure if our jmx impl could retain that kind of listener or if it would be dropped during the reload. Probably a listener added via some -javaagent hook or something would be present during first boot and retained during reload as that listener would have been registered with the original platform mbeanserver.
> Managmement and JMX notifications when ControlledProcessState changes
> ---------------------------------------------------------------------
>
> Key: WFCORE-1157
> URL: https://issues.jboss.org/browse/WFCORE-1157
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 3.0.0.Alpha1
>
>
> When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5170) WildFlySecurityManager throws exception by some tests with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5170?page=com.atlassian.jira.plugin.... ]
Ivo Studensky resolved WFLY-5170.
---------------------------------
Resolution: Done
The new org.wildfly.naming module is the default dependency of any EE deployment, thus there is no need for an explicit dependency on it in meta-inf.
> WildFlySecurityManager throws exception by some tests with security manager
> ---------------------------------------------------------------------------
>
> Key: WFLY-5170
> URL: https://issues.jboss.org/browse/WFLY-5170
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ivo Studensky
> Fix For: 10.0.0.CR5
>
>
> *Description of problem:*
> WildFlySecurityManager throws ExceptionInInitializerError exception by some tests with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.batch.deployment.JobControlTestCase#testStop
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20MessageSelectorTestCase#retestMessageSelectors
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase#testEjb20MDB
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase#testEjb20TopicMDBs
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB21TestCase#testSimple21MDB
> * org.jboss.as.test.integration.ejb.pool.lifecycle.PooledEJBLifecycleTestCase#testMDB
> * org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions
> * org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly
> * org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple
> *Steps to Reproduce for MDB20QueueTestCase:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=MDB20QueueTestCase
> *Actual results:*
> {noformat}
> testEjb20MDB(org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase) Time elapsed: 0.094 sec <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496)
> at java.lang.System.getProperty(System.java:717)
> at java.lang.Integer.getInteger(Integer.java:1101)
> at java.lang.Integer.getInteger(Integer.java:1057)
> at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase.testEjb20MDB(MDB20QueueTestCase.java:110)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years