[JBoss JIRA] (AS7-6699) AS7 messaging resources throws NPE when hornetq-server is a backup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6699?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6699:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 918131|https://bugzilla.redhat.com/show_bug.cgi?id=918131] from MODIFIED to ON_QA
> AS7 messaging resources throws NPE when hornetq-server is a backup
> ------------------------------------------------------------------
>
> Key: AS7-6699
> URL: https://issues.jboss.org/browse/AS7-6699
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha1
>
>
> steps to reproduce:
> Configure AS7's hornetq-server to be a backup ready for failover.
> Run AS7 standalone-full configuration with hornetq-server configured to be a backup:
> {noformat}
> <hornetq-server>
> <backup>true</backup>
> ...
> {noformat}
> The AS7 will start, its hornetq-server too *but* it will not be active:
> {noformat}
> 18:24:56,527 INFO [org.hornetq.core.server] (HQ119001: Activation for server HornetQServerImpl::serverUUID=349065dd-87f2-11e2-911d-f19bf97ea7a7) HQ002211: HornetQ Backup Server version 2.3.0.CR1 (buzzzzz!, 122) [349065dd-87f2-11e2-911d-f19bf97ea7a7] started, waiting live to fail before it gets active
> {noformat}
> The hornetq server will not become active until a live node fails. When this occurs, the server will become active, accept connection, create core and JMS resources etc.
> The issue is that any runtime operation on a hornetq-server's children will fail.
> The runtime operations rely on HornetQ's management resource (eg TopicControl, QueueControl) and these objects are not available until HornetQ server is active.
> For AS7 integration that means that we must somehow prevent any runtime changes to any hornetq-server's children resources for a passive server. There are no corresponding runtime resources in HornetQ for them.
> Additionnaly, hornetq-server does not expose the "active" runtime attribute to know whether the server is active.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6664?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6664:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 915317|https://bugzilla.redhat.com/show_bug.cgi?id=915317] from ASSIGNED to MODIFIED
> Unable to turn on/off logging handlers using enable()/disable() in CLI
> ----------------------------------------------------------------------
>
> Key: AS7-6664
> URL: https://issues.jboss.org/browse/AS7-6664
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Logging
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha1
>
>
> Peter Kremens reports:
> I am unable to use enable/disable operation in logging handlers.
>
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Calling disable() won't affect enabled attribute
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable()
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Must use write-attribute instead
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => false,
> ...
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6779:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 927318|https://bugzilla.redhat.com/show_bug.cgi?id=927318] from POST to MODIFIED
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Attachments: AS7-6779.out2.txt, AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145] from POST to MODIFIED
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6826) Add Support for Equinox ForkJoinPool
by Philippe Marschall (JIRA)
Philippe Marschall created AS7-6826:
---------------------------------------
Summary: Add Support for Equinox ForkJoinPool
Key: AS7-6826
URL: https://issues.jboss.org/browse/AS7-6826
Project: Application Server 7
Issue Type: Enhancement
Components: EE
Reporter: Philippe Marschall
Assignee: David Lloyd
Unfortunately JSR-236 does not address Java 7 fork/join pools. This puts people how want to use fork/join pools in an awkward position, either don't use them and wait for EE 8 (four or five years) or violate the "contract" and just create them anyway.
This presents a great opportunity for AS8 to go further than the spec and provide a {{java.util.concurrent.ForkJoinPool}} and a {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}}. This allows us to innovate and standardize at a later time in EE 8 once we gained experience.
This should include the following features:
* Allow the configuration of {{java.util.concurrent.ForkJoinPool}} in the server configuration. You should be able to configure the parallelism and asyncMode (see constructor arguments). Similar to {{javax.enterprise.concurrent.ManagedExecutorService}}.
* Allow the injection of {{java.util.concurrent.ForkJoinPool}} configured in the server. Similar to {{javax.enterprise.concurrent.ManagedExecutorService}}.
* Allow the configuration of {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}} in the server configuration, merely to match the same feature in JSR-268.
* Allow the injection of {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}} configured in the server (similar to Infinispan), merely to match the same feature in JSR-268.
* {{java.util.concurrent.ForkJoinPool}} should per default not preserve the context http://java.net/projects/concurrency-ee-spec/lists/jsr236-experts/archive... (naming, security, transactions, class loading). Optionally you should be able to configure which contexts are preserved, this might be tough as {{ForkJoinPool}} is not designed for extensibility.
I'm well aware that this is unspecified behaviour but so is Infinispan in AS7 and AS8 since JSR-107 again didn't make it.
This issue is intended for AS8, not AS7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-80) Create a project that will allow Drools to be tested against many OSGi frameworks
by Cristiano Gavião (JIRA)
[ https://issues.jboss.org/browse/DROOLS-80?page=com.atlassian.jira.plugin.... ]
Cristiano Gavião commented on DROOLS-80:
----------------------------------------
Initially was added only tests for bundle installation. Next step is to create tests to ensure that Drools OSGi services are being published properly.
> Create a project that will allow Drools to be tested against many OSGi frameworks
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-80
> URL: https://issues.jboss.org/browse/DROOLS-80
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Cristiano Gavião
> Assignee: Mark Proctor
> Labels: OSGi
>
> The actual project that tests Drools in a OSGi platform was not defined for a reliable and consistent tests on more than one framework.
> So the propose is to create a new project that will use Pax-Exam tool which will able to test Drools bundles in the most important existent frameworks: Equinox, Felix and Knopflerfish.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Mike Harvey <mharvey(a)redhat.com> made a comment on [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145]
Acking on behalf of Pavel Slavicek.
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months