December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4593) Model-only representation

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4593?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4593. ---------------------------- > Model-only representation > ------------------------- > > Key: WFLY-4593 > URL: https://issues.jboss.org/browse/WFLY-4593 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha4 > > > Refactor the messaging subsystem to use ModelOnlyResource definition and remove all runtime code. > Remove also the org.hornetq and org.hornetq.ra) modules. > With WFLY-4584, a org.hornetq.client module is added to represent only the HornetQ client library (required for JMS forward compatibility) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5164) Upgrade Infinispan to 8.0.0.CR1

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5164?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5164. ---------------------------- > Upgrade Infinispan to 8.0.0.CR1 > ------------------------------- > > Key: WFLY-5164 > URL: https://issues.jboss.org/browse/WFLY-5164 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 10.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 10.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5298) JASPIC verifyResponse is not called if proactive authentication is not in use

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5298?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5298. ---------------------------- > JASPIC verifyResponse is not called if proactive authentication is not in use > ----------------------------------------------------------------------------- > > Key: WFLY-5298 > URL: https://issues.jboss.org/browse/WFLY-5298 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 10.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4811) Add batch-jberet subsystem to replace the original batch subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4811?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4811. ---------------------------- > Add batch-jberet subsystem to replace the original batch subsystem > ------------------------------------------------------------------ > > Key: WFLY-4811 > URL: https://issues.jboss.org/browse/WFLY-4811 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > Fix For: 10.0.0.Beta1 > > > The original batch subsystem will not work well with capabilities and requirements. It's also fairly limited in the validation it can offer for the job repositories. > Current model: > {code} > { > "outcome" => "success", > "result" => { > "job-repository-type" => "in-memory", > "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "max-threads" => 10, > "name" => "batch", > "thread-factory" => undefined > }} > } > } > {code} > The {{job-repository-type}} will be removed as well as the {{job-repository=jdbc}}. A new {{jdbc-job-repository}} and {{in-memory-job-repository}} resource will be added. There will also be a {{default-job-repository}} which will accept a name from one of the defined job repositories. > The {{jndi-name}} will no longer be used and a {{data-source}} name will be used for the JDBC job repository. For example resource value might be {{ExampleDS}}. > A new deployment descriptor will be added to allow a user to defined a job repository configured on the subsystem. > Due to these changes the persisted XML will likely need some small alterations. Mainly ensuring a name attribute is persisted and multiple repositories are allowed to be defined. > The current batch subsystem will remain. It will allow the server to boot with old configurations, but the default with be the new {{batch-jberet}} subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4799) cancelled ejb timers persist in data/timer-service-data

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4799?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4799. ---------------------------- > cancelled ejb timers persist in data/timer-service-data > ------------------------------------------------------- > > Key: WFLY-4799 > URL: https://issues.jboss.org/browse/WFLY-4799 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR2 > Environment: linux 4.0.4-303.fc22.x86_64, java jdk1.8.0_45 and wildfly-9.0.0.CR2 > Reporter: John Whitley > Assignee: jaikiran pai > Labels: jboss > Fix For: 9.0.0.Final, 10.0.0.Alpha4 > > Attachments: timertest.tgz > > > I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness. > In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4697) EJBClient access to SFSBs does not play well with clean shutdown

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4697?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4697. ---------------------------- > EJBClient access to SFSBs does not play well with clean shutdown > ---------------------------------------------------------------- > > Key: WFLY-4697 > URL: https://issues.jboss.org/browse/WFLY-4697 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB, Remoting > Affects Versions: 10.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Fix For: 10.0.0.Alpha4 > > > The clean shutdown mechanism allows EJB and web applications to make use of shutdown interceptors to allow the application server to refuse requests when a server is in the process of shutting down. These interceptors are tied to the processing of EJB invocations and web requests. > In the case of EJBCLient invocations, they arrive at the remoting connector, and undergo some preliminary processing before being sent to the EJB interface in question. When a server is shutting down, EJBCLient invocations can arrive at the RemoteConnector and start processing, even when the EJB interface has been locked down, so to speak. > I am seeing various types of exceptions arising from this preliminary processing (e.g. NPE on DeploymentRepository lookups) and these get returned to the client as exceptions on the SFSB invocation, before even reaching the SFSB interceptors. > If the EJBCLient is running in a managed transaction context, these returned exceptions will case the SFSB to be discarded (as the SFSB invocation is considered failed with the exception returned) and the transaction will attempt to rollback. If the rollback processing fails (because the original node in the transaction is down the bean gets removed anyway. The SFSB session state is lost, even if there is another node in the cluster which can support the invocation. > In short, it looks as though the clean shutdown mechanism needs to be used to also lock down the processing of EJBCLient invocations in some way. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4594) Move messaging subsystem to legacy/

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4594?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4594. ---------------------------- > Move messaging subsystem to legacy/ > ----------------------------------- > > Key: WFLY-4594 > URL: https://issues.jboss.org/browse/WFLY-4594 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1247) graceful shutdown

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1247?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-1247. ---------------------------- > graceful shutdown > ----------------- > > Key: WFLY-1247 > URL: https://issues.jboss.org/browse/WFLY-1247 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Stuart Douglas > Fix For: 10.0.0.Beta1 > > > We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4964) java.lang.IllegalStateException: channel is closed when using JGroups for HA replication

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4964?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4964. ---------------------------- > java.lang.IllegalStateException: channel is closed when using JGroups for HA replication > ---------------------------------------------------------------------------------------- > > Key: WFLY-4964 > URL: https://issues.jboss.org/browse/WFLY-4964 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Alpha5 > Reporter: Ondřej Kalman > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR1 > > > I'm getting this exception when I try to use <replication-master> and JGroups for cluster discovery: > AMQ222116: unable to start broadcast group bg-group1: java.lang.IllegalStateException: channel is closed > at org.jgroups.JChannel.checkClosed(JChannel.java:959) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel._preConnect(JChannel.java:548) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel.connect(JChannel.java:288) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openBroadcaster(JGroupsBroadcastEndpoint.java:101) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.cluster.impl.BroadcastGroupImpl.start(BroadcastGroupImpl.java:105) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.cluster.ClusterManager.start(ClusterManager.java:288) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1904) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:104) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:416) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:414) [artemis-jms-server-1.0.0.jar:1.0.0] > at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:173) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:60) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:94) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.0.Final.jar:2.2.0.Final] > This issue seems to be the same as: https://issues.apache.org/jira/browse/ARTEMIS-103 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4797) Adjustments for ordered-child-resources

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4797?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4797. ---------------------------- > Adjustments for ordered-child-resources > --------------------------------------- > > Key: WFLY-4797 > URL: https://issues.jboss.org/browse/WFLY-4797 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 10.0.0.Alpha5 > > > https://github.com/wildfly/wildfly-core/pull/813 for WFCORE-759 deprecates some methods, which need to be removed once PR 813 has been merged and released. These changes will come in a future core release, but first we need to update the usage in Full (currently only in JGroups). > Also, the @Override should be uncommented for https://github.com/wildfly/wildfly/pull/7611/files -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017