[JBoss JIRA] (WFCORE-542) Deprecate DeploymentUnit deployment resource methods and create new API
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-542?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-542:
---------------------------------
Description: Deprecate the methods that interact with the deployments subsystem resources. Create a new API attached to the deployment unit to interact with the deployments resources. (was: Deprecate the methods that interact with the )
> Deprecate DeploymentUnit deployment resource methods and create new API
> -----------------------------------------------------------------------
>
> Key: WFCORE-542
> URL: https://issues.jboss.org/browse/WFCORE-542
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: James Perkins
> Assignee: James Perkins
>
> Deprecate the methods that interact with the deployments subsystem resources. Create a new API attached to the deployment unit to interact with the deployments resources.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-542) Deprecate DeploymentUnit deployment resource methods and create new API
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-542?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-542:
---------------------------------
Summary: Deprecate DeploymentUnit deployment resource methods and create new API (was: Clarify the JavaDoc for DeploymentUnit sub-models)
> Deprecate DeploymentUnit deployment resource methods and create new API
> -----------------------------------------------------------------------
>
> Key: WFCORE-542
> URL: https://issues.jboss.org/browse/WFCORE-542
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: James Perkins
> Assignee: James Perkins
>
> The {{DeploymentUnit.getDeploymentSubsystemModel()}} and the {{DeploymentUnit.createDeploymentSubModel()}} methods were somewhat generic the documentation. The documentation needs to be clarified and the implementation needs to conform to the clarified documentation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4396) mod_cluster subsystem find any http server on the network
by Jose Diaz (JIRA)
Jose Diaz created WFLY-4396:
-------------------------------
Summary: mod_cluster subsystem find any http server on the network
Key: WFLY-4396
URL: https://issues.jboss.org/browse/WFLY-4396
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 8.2.0.Final
Environment: Ubuntu 14.04, wildfly 8.2.0.final, apache http server 2.2.29
Reporter: Jose Diaz
Assignee: Paul Ferraro
Priority: Critical
I configure a Load Balanced HA Standalone Cluster, in my machine however in the network there is other apache http server when I wake up the server I get the next error:
MODCLUSTER000043: Failed to send INFO to 10.21.51.121/10.21.51.121:22001: java.net.NoRouteToHostException: No existe ninguna ruta hasta el «host»
I configure the mod_cluster in standalone-full-ha with:
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
<mod-cluster-config advertise-socket="modcluster" proxy-list="127.0.0.1:80" balancer="jdcluster" connector="ajp">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
</mod-cluster-config>
</subsystem>
Then get the same error.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ]
Cheng Fang edited comment on WFLY-4390 at 2/28/15 10:54 AM:
------------------------------------------------------------
Fixed in project JBeret:
https://github.com/jberet/jsr352/commit/eed55070a42bbd15240e14b638fb12ea8...
Also tested with attached batch-restartable.zip test against WildFly 9 snapshot.
{code}
2015-02-28 08:21:37,154 INFO [com.example.batch.UnrestartableBatchTest] (default task-1) $$$ start(): jobid: 58, status: FAILED
2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) javax.batch.operations.JobRestartException: JBERET000646: The job with name: unrestartable-job, execution id: 58, is configured not restartable
2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at org.jberet.operations.JobOperatorImpl.restart(JobOperatorImpl.java:210)
2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at com.example.batch.UnrestartableBatchTest.testRestartAfterException(UnrestartableBatchTest.java:57)
{code}
was (Author: cfang):
Fixed in project JBeret:
https://github.com/jberet/jsr352/commit/eed55070a42bbd15240e14b638fb12ea8...
Also tested with attached batch-restartable.zip test against WildFly 9 snapshot.
> restartable=false bach job can be restarted
> -------------------------------------------
>
> Key: WFLY-4390
> URL: https://issues.jboss.org/browse/WFLY-4390
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restartable.zip
>
>
> The batch job defined with restartable=false must not be restartable, after failed or stopped.
> GlassFish 4.1 results in the following:
> [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[
> javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted.
> But WildFly tries to execute the stopped or failed job.
> Please check the attached test case.
> wildfly:
> $ mvn clean test -P wildfly-managed (or -P wildly-remote)
> glassfish:
> $ glassfish4/bin/asadmin start-domain
> $ mvn clean test -P glassfish-remote
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4390:
----------------------------------
Updated WildFly batch sample app to verify restartable attribute, especially restart a previously failed job execution after a WildFly restart, to make sure the decision to disallow restart in the old job execution is persisted and subsequently retrieved and honored by the restart operation.
https://github.com/chengfang/wildfly-samples/tree/master/jberet/deseriali...
> restartable=false bach job can be restarted
> -------------------------------------------
>
> Key: WFLY-4390
> URL: https://issues.jboss.org/browse/WFLY-4390
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restartable.zip
>
>
> The batch job defined with restartable=false must not be restartable, after failed or stopped.
> GlassFish 4.1 results in the following:
> [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[
> javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted.
> But WildFly tries to execute the stopped or failed job.
> Please check the attached test case.
> wildfly:
> $ mvn clean test -P wildfly-managed (or -P wildly-remote)
> glassfish:
> $ glassfish4/bin/asadmin start-domain
> $ mvn clean test -P glassfish-remote
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4390:
----------------------------------
Fixed in project JBeret:
https://github.com/jberet/jsr352/commit/eed55070a42bbd15240e14b638fb12ea8...
Also tested with attached batch-restartable.zip test against WildFly 9 snapshot.
> restartable=false bach job can be restarted
> -------------------------------------------
>
> Key: WFLY-4390
> URL: https://issues.jboss.org/browse/WFLY-4390
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Cheng Fang
> Attachments: batch-restartable.zip
>
>
> The batch job defined with restartable=false must not be restartable, after failed or stopped.
> GlassFish 4.1 results in the following:
> [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[
> javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted.
> But WildFly tries to execute the stopped or failed job.
> Please check the attached test case.
> wildfly:
> $ mvn clean test -P wildfly-managed (or -P wildly-remote)
> glassfish:
> $ glassfish4/bin/asadmin start-domain
> $ mvn clean test -P glassfish-remote
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JGRP-1918) ConcurrentModificationException in Locking notification
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1918?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1918:
---------------------------
Fix Version/s: 3.6.3
> ConcurrentModificationException in Locking notification
> -------------------------------------------------------
>
> Key: JGRP-1918
> URL: https://issues.jboss.org/browse/JGRP-1918
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Environment: JUnit text running in Eclipse on Windows
> Reporter: Paul Illingworth
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I have code which unregisters a lock listener whilst a lock notification event is being fired leading to
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
> at java.util.HashMap$KeyIterator.next(HashMap.java:960)
> at org.jgroups.protocols.Locking.notifyUnlocked(Locking.java:581)
> at org.jgroups.protocols.Locking$ServerLock.setOwner(Locking.java:767)
> at org.jgroups.protocols.Locking$ServerLock.handleRequest(Locking.java:655)
> at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:393)
> at org.jgroups.protocols.Locking.up(Locking.java:226)
> at org.jgroups.stack.Protocol.up(Protocol.java:412)
> at org.jgroups.protocols.FORK.up(FORK.java:139)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1087)
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:886)
> at org.jgroups.protocols.UNICAST3.handleDataReceivedFromSelf(UNICAST3.java:821)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:424)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD.up(FD.java:253)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2842)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> The org.jgroups.protocols.Locking#lock_listeners is simple a HashSet which gets iterated over, This needs to be synchronised is some way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Eduardo Martins edited comment on WFLY-4384 at 2/28/15 2:16 AM:
----------------------------------------------------------------
The "execution" property is related to the thread invoking/executing the contextual object, which may not be the thread creating that object. In your example code the executing thread is a ManagedExecutorService internal thread, which has no transaction.
You can see an example of its usage at [http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe...]
was (Author: emmartins):
The "execution" property is related to the thread invoking/executing the contextual object, which may not be the thread creating that object. In your example code the executing thread is a ManagedExecutorService internal thread, which has no transaction.
You can see an example of its usage at http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe...
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-4384:
---------------------------------------
The "execution" property is related to the thread invoking/executing the contextual object, which may not be the thread creating that object. In your example code the executing thread is a ManagedExecutorService internal thread, which has no transaction.
You can see an example of its usage at http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe...
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month