[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Ben Johnson (JIRA)
[ https://issues.jboss.org/browse/JGRP-1979?page=com.atlassian.jira.plugin.... ]
Ben Johnson updated JGRP-1979:
------------------------------
Attachment: CacheTest.java
Cache.java
> org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
> ---------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1979
> URL: https://issues.jboss.org/browse/JGRP-1979
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1, 3.6.6
> Environment: Windows 10 64-bit
> Reporter: Ben Johnson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
> Attachments: Cache.java, Cache.java, CacheTest.java, CacheTest.java
>
>
> org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
> I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Ben Johnson (JIRA)
[ https://issues.jboss.org/browse/JGRP-1979?page=com.atlassian.jira.plugin.... ]
Ben Johnson reopened JGRP-1979:
-------------------------------
Hi Bela
I just discovered a bug with my fix - get() now returns the value even if it is expired, whereas before it returned null. I've fixed this, and also written a more comprehensive set of unit tests for Cache.java as well. Note that I changed the 'change_listeners' variable from a HashSet to LinkedHashSet to simplify testing of the listener logic.
Ben
> org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
> ---------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1979
> URL: https://issues.jboss.org/browse/JGRP-1979
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1, 3.6.6
> Environment: Windows 10 64-bit
> Reporter: Ben Johnson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
> Attachments: Cache.java, CacheTest.java
>
>
> org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
> I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5684) Injection of ArquillianResource URL fails in Wildfly 10 CR4
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5684?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5684:
-----------------------------------
That is interesting.
What do you get as result of running
/socket-binding-group=*/socket-binding=*:read-resource
in CLI?
> Injection of ArquillianResource URL fails in Wildfly 10 CR4
> -----------------------------------------------------------
>
> Key: WFLY-5684
> URL: https://issues.jboss.org/browse/WFLY-5684
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR4
> Reporter: John Ament
> Assignee: Jason Greene
>
> I recently added injection of an ArquillianResource URL to a test. I also just tried upgrading from WF9 to WF10.CR4. In CR4, it seems that this injection is working a bit weird.
> My injection is very simple
> {code}
> @ArquillianResource
> private URL url;
> {code}
> However, I see this output when running (note that my HTTP listener is on 8082)
> {code}
> 11:37:40,922 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) I/O exception (java.net.SocketException) caught when connecting to {}->http://[::]:8082: Network is unreachable
> 11:37:40,922 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) Retrying connect to {}->http://[::]:8082
> 11:37:47,069 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) I/O exception (java.net.SocketException) caught when connecting to {}->http://[::]:8082: Network is unreachable
> 11:37:47,069 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) Retrying connect to {}->http://[::]:8082 11:37:54,163 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) I/O exception (java.net.SocketException) caught when connecting to {}->http://[::]:8082: Network is unreachable
> 11:37:54,163 INFO [org.apache.http.impl.client.DefaultHttpClient] (default task-46) Retrying connect to {}->http://[::]:8082
> {code}
> It would appear that the host portion of the URL is being lost.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4840) Deprecated element cluster-passivation-store from ejb subsystem does not work
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4840?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-4840:
----------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> 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)
10 years, 8 months
[JBoss JIRA] (WFLY-5687) max-active-sessions doesn't work with enabled statistics
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5687:
--------------------------------------
Summary: max-active-sessions doesn't work with enabled statistics
Key: WFLY-5687
URL: https://issues.jboss.org/browse/WFLY-5687
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
When having defined max-active-sessions and enabled statistics {{/subsystem=undertow:write-attribute(name=statistics-enabled, value=true)}} the setting of max-active-sessions is ignored.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-4608:
-----------------------------------
More stuff:
{quote}
The {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}}, {{PostActivate}}, and/or {{ejbCreate<METHOD>}}, {{ejbRemove}}, {{ejbPassivate}}, and {{ejbActivate}} methods of a stateful session bean with container-managed transaction demarcation are invoked in the scope of a transaction determined by the transaction attribute specified in the bean’s metadata annotations or deployment descriptor.
{quote}
{quote}
By default a stateful session bean’s {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} and {{PostActivate}} methods are executed in an unspecified transactional context. A {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} and {{PostActivate}} method of a stateful session bean with container-managed transaction demarcation is permitted to have transaction attribute {{REQUIRES_NEW}} or {{NOT_SUPPORTED}} ({{RequiresNew}} or {{NotSupported}} if the deployment descriptor is used to specify the transaction attribute).
{quote}
{quote}
The {{PostConstruct}} and {{PreDestroy}} methods of singleton session beans with container-managed transaction demarcation can be invoked with or without a transaction. From the Bean Provider’s view there is no client of a {{PostConstruct}} or {{PreDestroy}} method.
A {{PostConstruct}} or {{PreDestroy}} method of a singleton session bean with container-managed transaction demarcation is permitted to have transaction attribute {{REQUIRED}}, {{REQUIRES_NEW}}, or {{NOT_SUPPORTED}} ({{Required}}, {{RequiresNew}}, or {{NotSupported}} if the deployment descriptor is used to specify the transaction attribute).
_Note that the container must start a new transaction if the {{REQUIRED}} ({{Required}}) transaction attribute is used. This guarantees, for example, that the transactional behavior of the {{PostConstruct}} method is the same regardless of whether the singleton session bean instance is initialized eagerly at container startup time or as a side effect of a first client invocation on the singleton session bean. The {{REQUIRED}} transaction attribute value is allowed so that specification of a transaction attribute for the singleton session bean’s {{PostConstruct}} and {{PreDestroy}} methods can be defaulted._
{quote}
{quote}
Lifecycle callback interceptor methods are invoked in an unspecified transaction context, except for singleton and stateful session bean {{PostConstruct}} and {{PreDestroy}} methods and stateful session bean {{PostActivate}}, and {{PrePassivate}} methods, whose transaction context is based on their respective transaction attributes.
{quote}
{quote}
By default, the value of the transaction attribute for a method of a bean with container-managed transaction demarcation is the {{REQUIRED}}
transaction attribute, and the transaction attribute does not need to be explicitly specified in this case. A transaction attribute is a value associated with each of the following methods:
* a method of a bean’s business interface
* a method exposed through the bean class no-interface view
* a message listener method of a message-driven bean
* a timeout callback method
* a stateless or singleton session bean’s web service endpoint method
* for beans written to the EJB 2.1 and earlier client view, a method of a session bean’s home or component interface
* a {{PostConstruct}} or {{PreDestroy}} lifecycle callback interceptor method of a singleton session bean
* a {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} or {{PostActivate}} lifecycle callback interceptor method of a stateful session bean
{quote}
{quote}
Transaction attributes are specified for the following methods:
* For a session bean written to the EJB 3.x client view API, the transaction attributes are specified for those methods of the session bean class that correspond to the bean’s business interface, the direct and indirect superinterfaces of the business interface, methods exposed through the bean class no-interface view, and for the timeout callback methods, if any.
* For a stateless session bean or singleton session bean that provides a web service client view, the transaction attributes are specified for the bean’s web service endpoint methods, and for the timeout callback methods, if any.
* For a singleton session bean, the transaction attributes are specified for the {{PostConstruct}} and {{PreDestroy}} lifecycle callback interceptor methods, if any. In order to specify the transaction attribute for a {{PostConstuct}} or {{PreDestroy}} method of a singleton session bean, the transaction attribute must be specified for the method(s) on the bean class, rather than for a superclass or {{PostConstruct}} or {{PreDestroy}} interceptor method.
* For a stateful session bean, the transaction attributes are specified for the {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} or {{PostActivate}} lifecycle callback interceptor methods, if any. In order to specify the transaction attribute for a {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} or {{PostActivate}} method of a stateful session bean, the transaction attribute must be specified for the method(s) on the bean class, rather than for a superclass or {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} or {{PostActivate}} interceptor method.
* For a message-driven bean, the transaction attributes are specified for the message listener-methods on the message-driven bean class and for the timeout callback methods, if any.
* For a session bean written to the EJB 2.1 and earlier client view, the transaction attributes are specified for the methods of the component interface and all the direct and indirect superinterfaces of the component interface, excluding the methods of the {{javax.ejb.EJBObject}} or {{javax.ejb.EJBLocalObject}} interface; and for the timeout callback methods, if any. Transaction attributes must not be specified for the methods of a session bean’s home interface.
By default, if a {{TransactionAttribute}} annotation is not specified for a method of an enterprise
bean with container-managed transaction demarcation, the value of the transaction attribute for the
method is defined to be {{REQUIRED}}. The rules for the specification of transaction attributes are defined
in Section 8.3.7.1.
{quote}
{quote}
For a singleton session bean’s {{PostConstruct}} and {{PreDestroy}} lifecycle callback interceptor methods, only the {{REQUIRED}}, {{REQUIRES_NEW}}, and {{NOT_SUPPORTED}} transaction attributes may be used.
For a stateful session bean’s {{PostConstruct}}, {{PreDestroy}}, {{PrePassivate}} or {{PostActivate}} lifecycle callback interceptor methods, only the {{REQUIRES_NEW}} and {{NOT_SUPPORTED}} transaction attributes may be used.
If an enterprise bean implements the {{javax.ejb.SessionSynchronization}} interface or uses any of the session synchronization annotations, only the following values may be used for the transaction attributes of the bean’s methods: {{REQUIRED}}, {{REQUIRES_NEW}}, {{MANDATORY}}
{quote}
> Omit no-op transaction if lifecycle method is missing
> -----------------------------------------------------
>
> Key: WFLY-4608
> URL: https://issues.jboss.org/browse/WFLY-4608
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 10.0.0.Final
>
>
> LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-4608:
-----------------------------------
The EJB spec has this to say:
{quote}
The {{PostConstruct}} lifecycle callback interceptor methods for a stateless session bean execute in an
unspecified transaction context. The {{PostConstruct}} lifecycle callback interceptor methods for a
singleton session bean execute in a transaction context determined by the bean’s transaction manage-
ment type and any applicable transaction attribute. The {{PostConstruct}} lifecycle callback intercep-
tor methods for a stateful session bean execute in a transaction context determined by the lifecycle
callback method's transaction attribute.
{quote}
And likewise:
{quote}
The {{PreDestroy}} lifecycle callback interceptor methods for a stateless session bean execute in an
unspecified transaction context. The {{PreDestroy}} lifecycle callback interceptor methods for a single-
ton session bean execute in a transaction context determined by the bean’s transaction management type
and any applicable transaction attribute. The {{PreDestroy}} lifecycle callback interceptor methods for a
stateful bean execute in a transaction context determined by the lifecycle callback method’s transaction
attribute.
{quote}
And, for completeness:
{quote}
The {{PrePassivate}} and {{PostActivate}} lifecycle callback interceptor methods execute in a trans-
action context determined by the lifecycle callback method's transaction attribute.
{quote}
> Omit no-op transaction if lifecycle method is missing
> -----------------------------------------------------
>
> Key: WFLY-4608
> URL: https://issues.jboss.org/browse/WFLY-4608
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 10.0.0.Final
>
>
> LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months