[JBoss JIRA] (WFLY-3402) Patch upload in console does not work
by Emanuel Muckenhuber (JIRA)
Emanuel Muckenhuber created WFLY-3402:
-----------------------------------------
Summary: Patch upload in console does not work
Key: WFLY-3402
URL: https://issues.jboss.org/browse/WFLY-3402
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.1.0.CR2
Reporter: Emanuel Muckenhuber
Assignee: Emanuel Muckenhuber
Priority: Critical
Fix For: 8.1.0.Final
The domain http upload handler behaves a bit different than the version in EAP and the way the console uploads streams does not work in upstream. We probably should just change it to the way EAP processes requests.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1841) Discovery: reduce number of discovery requests to backend store
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1841:
--------------------------------
I observed that requests to the Google Cloud Store can take *up to a few hundred milliseconds* ! This cannot scale if we send a LIST and then 1000 GET requests (for a 1000 node cluster). Accessing the members file should get us constant access times...
> Discovery: reduce number of discovery requests to backend store
> ----------------------------------------------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
> This is mainly done by
> * Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
> * Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
> For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
> Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
> The _members file_ lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> The file could be located on a (shared) file system, S3, a DB table or a cloud store.
> *This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> h5. The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> * Reducing the number of calls to the cloud store (latency!)
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> h5. References
> See https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedDisco... for the design
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-784) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-784?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar closed WFLY-784.
----------------------------
Assignee: Tomaz Cerar (was: Paul Gier)
Resolution: Done
[~mikevan] sorry this is still open, can you verify this is still problem for your with latest as / WildFly codebase?
As I could not reproduce the problem, or even remember seeing this problem.
I am closing this issue as I believe problem originates from improperly building arquillian modules, as this should be build as part of whole build not just sub module "arquillian"
Anyhow, if this problem persists for your please reopen the issue, and if you do sent updated patch, do so by opening pull request. Thank you.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: WFLY-784
> URL: https://issues.jboss.org/browse/WFLY-784
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Tomaz Cerar
> Labels: Arquillian
> Attachments: 0001-Moved-testng-integration-to-the-base-directory-and-m.patch, AS7-6248-patch.txt
>
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-501) jBPM Ruleflow groups ignore no-loops when nodes are shared
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-501:
-------------------------------------
Summary: jBPM Ruleflow groups ignore no-loops when nodes are shared
Key: DROOLS-501
URL: https://issues.jboss.org/browse/DROOLS-501
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta4
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Critical
Fix For: 6.1.0.CR1
The following rules
{code}
package org.drools.compiler.loop
rule "Rule 1"
ruleflow-group "Start"
no-loop
when
$thing1 : String()
$thing2 : Integer()
then
System.out.println( 'At 1' );
update( $thing2 );
end
rule "Rule 2"
ruleflow-group "End"
no-loop
when
$thing1 : String()
$thing2 : Integer()
then
System.out.println( 'At 2' );
update( $thing2 );
end
{code}
cause an endless loop even if controlled by a jBPM process with two rule tasks
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3396) NPE in TimerResourceDefinition
by Serge Mürset (JIRA)
[ https://issues.jboss.org/browse/WFLY-3396?page=com.atlassian.jira.plugin.... ]
Serge Mürset updated WFLY-3396:
-------------------------------
Description:
I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to one of my own scheduled EJB.
Stacktrace:
{code}
10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
("deployment" => "core-dist-0.6.ear"),
("subdeployment" => "core.jar"),
("subsystem" => "ejb3"),
("singleton-bean" => "FileDeploymentScanner"),
("service" => "timer-service"),
("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
]): java.lang.NullPointerException
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
The arquillian test prints:
{code}
com.ieffects.core.integration.ImportTest STANDARD_ERROR
May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.2.Final
May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.2.Final
May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.3.Final
May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
ERROR: Operation {
"operation" => "read-resource",
"recursive" => "true",
"address" => undefined
} did not succeed. Result was {
"outcome" => "failed",
"result" => {
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
"name" => "cust",
"namespaces" => [],
"product-name" => undefined,
"product-version" => undefined,
"profile-name" => undefined,
"release-codename" => "Kenny",
"release-version" => "8.1.0.CR2",
"schema-locations" => [],
"core-service" => {
"management" => {
"access" => {
"authorization" => {
... the complete wildfly configuration...
},
"rolled-back" => true
}
{code}
My scheduled Service FileDeploymentScanner is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
{code}
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@Startup
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class FileDeploymentScanner {
@Resource
private TimerService _timerService;
/**
* Scans and deploys files according to configuration.
*/
@Timeout
public void handleClick() {
System.out.println("handle click");
}
/**
* Initializes the service.
*/
@PostConstruct
public void startup() {
System.out.println("Starting timer service");
_timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Started timer service");
}
}
{code}
What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
was:
I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to some TimerService EJB.
Stacktrace:
{code}
10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
("deployment" => "core-dist-0.6.ear"),
("subdeployment" => "core.jar"),
("subsystem" => "ejb3"),
("singleton-bean" => "FileDeploymentScanner"),
("service" => "timer-service"),
("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
]): java.lang.NullPointerException
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
The arquillian test prints:
{code}
com.ieffects.core.integration.ImportTest STANDARD_ERROR
May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.2.Final
May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.2.Final
May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.3.Final
May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
ERROR: Operation {
"operation" => "read-resource",
"recursive" => "true",
"address" => undefined
} did not succeed. Result was {
"outcome" => "failed",
"result" => {
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
"name" => "cust",
"namespaces" => [],
"product-name" => undefined,
"product-version" => undefined,
"profile-name" => undefined,
"release-codename" => "Kenny",
"release-version" => "8.1.0.CR2",
"schema-locations" => [],
"core-service" => {
"management" => {
"access" => {
"authorization" => {
... the complete wildfly configuration...
},
"rolled-back" => true
}
{code}
The TimerService is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
{code}
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@Startup
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class MyTimerService {
@Resource
private TimerService _timerService;
/**
* Scans and deploys files according to configuration.
*/
@Timeout
public void handleClick() {
System.out.println("handle click");
}
/**
* Initializes the service.
*/
@PostConstruct
public void startup() {
System.out.println("Starting timer service");
_timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Started timer service");
}
}
{code}
What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
> NPE in TimerResourceDefinition
> ------------------------------
>
> Key: WFLY-3396
> URL: https://issues.jboss.org/browse/WFLY-3396
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.CR2
> Environment: JDK 1.7.0_55
> MacOSX
> PostgreSQL 9.1
> Wildfly 8.1.0.CR2
> Arquillian 1.1.2.Final-wildfly-1
> arquillian-protocol-servlet 1.1.2.Final-wildfly-1
> wildfly-arquillian-container-remote 8.1.0.CR2
> Reporter: Serge Mürset
> Assignee: Stuart Douglas
> Labels: race-condition, wildfly
>
> I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to one of my own scheduled EJB.
> Stacktrace:
> {code}
> 10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
> 10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
> ("deployment" => "core-dist-0.6.ear"),
> ("subdeployment" => "core.jar"),
> ("subsystem" => "ejb3"),
> ("singleton-bean" => "FileDeploymentScanner"),
> ("service" => "timer-service"),
> ("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
> ]): java.lang.NullPointerException
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> The arquillian test prints:
> {code}
> com.ieffects.core.integration.ImportTest STANDARD_ERROR
> May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.2.Final
> May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.2.Final
> May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.3.Final
> May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
> ERROR: Operation {
> "operation" => "read-resource",
> "recursive" => "true",
> "address" => undefined
> } did not succeed. Result was {
> "outcome" => "failed",
> "result" => {
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> "name" => "cust",
> "namespaces" => [],
> "product-name" => undefined,
> "product-version" => undefined,
> "profile-name" => undefined,
> "release-codename" => "Kenny",
> "release-version" => "8.1.0.CR2",
> "schema-locations" => [],
> "core-service" => {
> "management" => {
> "access" => {
> "authorization" => {
> ... the complete wildfly configuration...
> },
> "rolled-back" => true
> }
> {code}
> My scheduled Service FileDeploymentScanner is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
> {code}
> @ConcurrencyManagement(ConcurrencyManagementType.BEAN)
> @Singleton
> @Startup
> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> public class FileDeploymentScanner {
> @Resource
> private TimerService _timerService;
> /**
> * Scans and deploys files according to configuration.
> */
> @Timeout
> public void handleClick() {
> System.out.println("handle click");
> }
> /**
> * Initializes the service.
> */
> @PostConstruct
> public void startup() {
> System.out.println("Starting timer service");
> _timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
> try {
> Thread.sleep(10000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> System.out.println("Started timer service");
> }
> }
> {code}
> What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1843) Look harder for SASL factories
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1843:
-------------------------------------
Summary: Look harder for SASL factories
Key: JGRP-1843
URL: https://issues.jboss.org/browse/JGRP-1843
Project: JGroups
Issue Type: Enhancement
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
If jboss-sasl is in the classpath we want to also discover and expose its factories
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1832) Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1832:
---------------------------
Priority: Optional (was: Major)
> Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-1832
> URL: https://issues.jboss.org/browse/JGRP-1832
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4.3
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Priority: Optional
> Fix For: 3.4.5, 3.5
>
>
> JGroups binds multicast sockets using specific MulticastSocket constructors depending on the operating system (to avoid crosstalk issues).
> McastSenderTest and McastReceiverTest always bind the socket using the basic MulticastSocket(port) constructor.
> In order to more closely test the way JGroups will be sending and receiving the packets, these tests will be updated to bind the sockets the same way.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month