[JBoss JIRA] (WFLY-4840) Deprecated element cluster-passivation-store from ejb subsystem does not work
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4840?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-4840:
--------------------------------------
The way it currently works is you configure one or the other, not both and no aliases. So the old configuration still works. So you remove one and the other such as
{noformat}
[standalone@localhost:9990 /] /subsystem=ejb3/passivation-store=infinispan:remove
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:add
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb.cache.factory.distributable.infinispan is already registered",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9990 /] :reload
{noformat}
> Deprecated element cluster-passivation-store from ejb subsystem does not work
> -----------------------------------------------------------------------------
>
> Key: WFLY-4840
> URL: https://issues.jboss.org/browse/WFLY-4840
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ondřej Chaloupka
> Assignee: Radoslav Husar
>
> There is a mismatch in behaviour of deprecated element {{cluster-passivation-store}} under {{ejb}} subsystem.
> When element is deprecated still it should work and only prints warning that it's deprecated.
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:read-resource()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"ejb3\"),
> (\"cluster-passivation-store\" => \"infinispan\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> but
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:add()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb.cache.factory.distributable.infinispan is already registered",
> "rolled-back" => true
> }
> {code}
> _A note:_ the element {{cluster-passivation-store}} was replaced by {{passivation-store}} which works fine
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6127) JPA specification - section 7.6.4.1 - Violation?
by Mazen Mahmoud (JIRA)
Mazen Mahmoud created WFLY-6127:
-----------------------------------
Summary: JPA specification - section 7.6.4.1 - Violation?
Key: WFLY-6127
URL: https://issues.jboss.org/browse/WFLY-6127
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 9.0.2.Final
Reporter: Mazen Mahmoud
Assignee: Scott Marlow
Priority: Minor
SPEC: If a component is called and the JTA transaction is propagated into that component:
If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6126) Upgrade Infinispan to 8.1.2.Final
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6126:
------------------------------------
Summary: Upgrade Infinispan to 8.1.2.Final
Key: WFLY-6126
URL: https://issues.jboss.org/browse/WFLY-6126
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
At this point pretty much a tracker Jira to enumerate expected fixes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6021?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6021:
--------------------------------
Fix Version/s: 10.1.0.Final
> Default transaction timeout is not applied for EJB bean when set for second time
> --------------------------------------------------------------------------------
>
> Key: WFLY-6021
> URL: https://issues.jboss.org/browse/WFLY-6021
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Fedor Gavrilov
> Fix For: 10.1.0.Final
>
>
> It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value.
> The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings.
> If the value is read from subsystem
> {{/subsystem=transactions:read-attribute(name=default-timeout)}}
> it shows correct value (that one set for second time). But EJB seems not applying it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-4936) JGroups: failed setting ip_ttl on windows with dual-stack IPv6 with "Method not implemented!"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4936?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4936:
---------------------------------
Fix Version/s: (was: 10.0.0.Final)
> JGroups: failed setting ip_ttl on windows with dual-stack IPv6 with "Method not implemented!"
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-4936
> URL: https://issues.jboss.org/browse/WFLY-4936
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Radoslav Husar
> Priority: Minor
>
> {noformat}
> 10:18:14,721 SEVERE [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=34818b2c-2b93-11e5-aeb7-199c6bd1db3c-31443612)) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
> at org.jgroups.protocols.UDP.start(UDP.java:270)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:891)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:92)
> at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:380)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:846)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:687)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:671)
> at org.apache.activemq.artemis.core.server.cluster.ClusterController$ConnectRunnable.run(ClusterController.java:448)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> 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.io.IOException: Method not implemented!
> at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
> ... 25 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-4936) JGroups: failed setting ip_ttl on windows with dual-stack IPv6 with "Method not implemented!"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4936?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reopened WFLY-4936:
----------------------------------
Fixing state, not merged yet.
> JGroups: failed setting ip_ttl on windows with dual-stack IPv6 with "Method not implemented!"
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-4936
> URL: https://issues.jboss.org/browse/WFLY-4936
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> {noformat}
> 10:18:14,721 SEVERE [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=34818b2c-2b93-11e5-aeb7-199c6bd1db3c-31443612)) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
> at org.jgroups.protocols.UDP.start(UDP.java:270)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:891)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:92)
> at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:380)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:846)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:687)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:671)
> at org.apache.activemq.artemis.core.server.cluster.ClusterController$ConnectRunnable.run(ClusterController.java:448)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> 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.io.IOException: Method not implemented!
> at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
> ... 25 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* DONE: Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
* Request<T>
* RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
* RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
* Rsp: see https://issues.jboss.org/browse/JGRP-2011
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * DONE: Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
> * Request<T>
> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps
> * RpcDispatcher: use CompletableFuture instead of NotifiyingFuture
> * DONE: Rsp: see https://issues.jboss.org/browse/JGRP-2011
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months