[JBoss JIRA] Created: (JBCACHE-880) Add expiration policy for nodes based on a node's expiration key
by Elias Ross (JIRA)
Add expiration policy for nodes based on a node's expiration key
----------------------------------------------------------------
Key: JBCACHE-880
URL: http://jira.jboss.com/jira/browse/JBCACHE-880
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
It is useful to specify an expiration time (TTL) for cache values individually. For example, in caching web page contents, the data should be retained based on the HTTP header "Expires". Or, for caching session data, it should be kept based on the user's preference, e.g. Yahoo! Mail allows the authentication credentials to be cached from 1-24 hours.
Example usage:
TreeCache cache;
Fqn fqn1 = new Fqn("node1");
Fqn fqn2 = new Fqn("node2");
cache.put(fqn1, "expiration", new Long( ... ));
cache.put(fqn1, "data", ... );
cache.put(fqn2, "expiration", new Long( ... ));
cache.put(fqn2, "data", ... );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBCACHE-834) Combine eviction RegionManager with generic RegionManager
by Manik Surtani (JIRA)
Combine eviction RegionManager with generic RegionManager
---------------------------------------------------------
Key: JBCACHE-834
URL: http://jira.jboss.com/jira/browse/JBCACHE-834
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.0.0.GA
This has already been done for the marshalling Regions and RegionManagers - do the same with eviction Regions and RegionManagers.
Also,
Another thing we need is equiv of the
o.j.c.eviction.RegionManager.markNodeCurrentlyInUse()/
unmarkNodeCurrentl yInUse() calls exposed in o.j.c.Region.
They are used by the LRUPolicy (and potentially others that implement
the feature) so the policy will ignore a node the app has marked "in
use".
Illustration of use by EJB3 SFSB:
1) User accesses bean.
2) StatefulTreeCache fetches bean from cache using get(). If no
transactional context at this point, RL from the get is released as soon
as method returns.
3) StatefulTreeCache call markNodeCurrentlyInUse
4) User invokes method on bean that takes a long time.
5) Eviction thread kicks in. Would ordinarily evict the bean since the
get() in #2 happened a while ago. But the node-in-use event tells it
not to.
6) User invocation finishes, bean is released.
7) StatefulTreeCache calls unmarkNodeCurrentlyInUse.
8) Bean can now be evicted on later eviction thread run.
I'd thought the changes were discussing of moving the lock interceptor
up in the order might help, but they don't -- as mentioned in step 2,
the bean can be "in use" long after any lock is held on its cache node.
Semantics we'd need are pretty much what we have now in 1.4 -- when
method is invoked, if the region is configured for eviction, create an
EvictedEventNode object and put it in the event queue. Only difference
is RegionManager doesn't get involved to find the region -- the app
should do that itself via the Cache API.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBAS-3616) failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
by Dimitris Andreadis (JIRA)
failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
-----------------------------------------------------------
Key: JBAS-3616
URL: http://jira.jboss.com/jira/browse/JBAS-3616
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Test Suite
Environment: Java Version 1.5.0_05
Java Vendor Sun Microsystems Inc.
Java VM Name Java HotSpot(TM) Server VM
Java VM Version 1.5.0_05-b05
Java VM Info mixed mode
OS Name Linux
OS Version 2.6.9-34.0.2.ELsmp
OS Arch i386
Reporter: Dimitris Andreadis
Fix For: JBossAS-4.0.5.GA
testMBeanInfoMarshalling Failure
Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBMESSAGING-527) JBoss Messaging should support JMSXDeliveryCount
by Joel Lindheimer (JIRA)
JBoss Messaging should support JMSXDeliveryCount
-------------------------------------------------
Key: JBMESSAGING-527
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-527
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: All
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Joel:
Here is an excerpt from theserverside which sums up the retry concept within a transaction well: http://www.theserverside.com/tt/articles/content/JMSArchitecture/JMSAppli...
For point-to-point messaging, when a transaction reads a message, the message becomes available to the transaction, but does not get physically removed from the destination at that time; instead, the messaging system leaves the message on the destination but does not allow other transactions to see it. When the transaction commits, the message is completely removed from the destination; however, if the transaction rolls back, the message stays on the destination and is now allowed to be read by other transactions.
Ovidiu:
Right. This is what Messaging does it. Though, to be 100% technically accurate, what it does is actually transacting acknowledgments. The message becomes available to the transaction, and it's the acknowledgment that is sent back to the channel in a transactional context. The acknowledgment is delivered to the channel (and the message removed from the channel) only when transaction commits.
This allows for a powerful feature called replay. Replay is the ability to retry the transaction after a rollback. The danger here is you can get caught in an infinite loop trying to replay the transaction. However, JMS systems can make use of the re-delivered count field on the message descriptor. Here, one can determine how many times the message has been re-delivered to a consumer and allow one to stop processing the message.
We're actually not supporting JMSXDeliveryCount yet, you're right here. The spec says it's optional. If it's important for you, just log a JIRA feature request, and we'll do it, subject to resource availability :).
Joel:
Thanks Ovidiu,
JMSXDeliveryCount is definitely a very high priority for us. With the rapid growing adoption of MDP use I imagine that I will be something that is also in high demand for the community at large. Furthermore, most JMS vendors support this behavior, so it probably makes sense for JBoss to put it on the roadmap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JGRP-355) STREAMING_STATE_TRANSFER doesn't work without FLUSH
by Bela Ban (JIRA)
STREAMING_STATE_TRANSFER doesn't work without FLUSH
---------------------------------------------------
Key: JGRP-355
URL: http://jira.jboss.com/jira/browse/JGRP-355
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
STREAMING_STATE_TRANSFER should work *without* FLUSH being required. STREAMING_STATE_TRANSFER.use_flush should be *overridden* and set to false if FLUSH is not present
<config>
<TCP_NIO
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
reader_threads="8"
writer_threads="8"
processor_threads="8"
processor_minThreads="8"
processor_maxThreads="8"
processor_queueSize="100"
processor_keepAliveTime="-1"/>
<MPING timeout="3000"
down_thread="false" up_thread="false"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STREAMING_STATE_TRANSFER down_thread="false" up_thread="false"
use_flush="true" use_reading_thread="true"/>
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/ -->
<!--pbcast.FLUSH down_thread="false" up_thread="false"/-->
</config>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (EJBTHREE-681) Ejb 3 Deployment separated into different jars that have persistence dependencies cause a jacc initialisation error
by Roland R?z (JIRA)
Ejb 3 Deployment separated into different jars that have persistence dependencies cause a jacc initialisation error
-------------------------------------------------------------------------------------------------------------------
Key: EJBTHREE-681
URL: http://jira.jboss.com/jira/browse/EJBTHREE-681
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC8 - FD
Reporter: Roland R?z
We separated the jboss trails deployment into two different jar's (persistence and stateless session beans).
The ear (ejb3-trials-ear.ear) contains two jar modules (ejb3-trials-ejb.jar & ejb3-trials-persistence.jar). The ejb3-trials-ejb.jar is deployed as fist module but it has a dependency to the ejb3-trials-persistence.jar because it uses the EntityManager from ejb3-trials-persistence.
Therefore the ejb container of ejb3-trials-ejb.jar is started after the ejb3-trials-ejb.jar modules. This causes an error with the jacc initialisation. The policy is committed before the ejb container could register is permissions. When the stateless ejb containers add the permissions afterwards, the committed policy will be removed and never committed again.
Because the ejb module commits the jacc policy, the ejb containers providing the permissions must be stated before the module.
Here the steps:
Ejb3Deployment.registerEJBContainer()
object name : jboss.j2ee:service=EJB3,ear=ejb3-trials-ear.ear,jar=ejb3-trials-ejb.jar,name=EntityCalculator
dependencies : persistence.units:ear=ejb3-trials-ear.ear,unitName=ejb3-trials-persistence
Ejb3Module.startService()
service name : jboss.j2ee:service=EJB3,module=ejb3-trials-ejb.jar
- JACC contextID ejb3-trials-ejb.jar is commited
-> This is an error because it should be waited until ALL container of this module are started
Ejb3Module.startService()
service name: jboss.j2ee:service=EJB3,module=ejb3-trials-persistence.jar
- dependencie from jar=ejb3-trials-ejb.jar to ejb3-trials-persistence.jar is resolved and the stateless container is started
StatelessContainer.start()
ejb3-trials-ejb.jar
- JACC contextID ejb3-trials-ejb.jar
Adds stuff to the policy
Ejb3Module.startService()
service name: jboss.j2ee:service=EJB3,module=ejb3-trials-persistence.jar
08:36:44,308 INFO [org.jboss.deployment.EARDeployer] Init J2EE application: file:/C:/eplatform/jboss/4.0/server/eplatform-development/deploy/ejb3-trials-ear.ear
08:36:44,428 WARN [org.jboss.deployment.MainDeployer] Found non-jar deployer for ejb3-trials-persistence.jar: MBeanProxyExt[jboss.ejb3:service=EJB3Deployer]
08:36:44,438 WARN [org.jboss.deployment.MainDeployer] Found non-jar deployer for ejb3-trials-persistence.jar: MBeanProxyExt[jboss.ejb3:service=EJB3Deployer]
08:36:44,599 INFO [org.jboss.ejb3.Ejb3Deployment] EJB3 deployment time took: 111
08:36:44,689 INFO [org.jboss.ejb3.Ejb3Deployment] EJB3 deployment time took: 50
08:36:44,759 INFO [org.jboss.deployment.ClientDeployer] Client ENC bound under: ejb3-trials-client
08:36:44,789 INFO [org.jboss.ejb3.JmxKernelAbstraction] installing MBean: jboss.j2ee:ear=ejb3-trials-ear.ear,jar=ejb3-trials-ejb.jar,name=EntityCalculator,service=EJB3 with dependencies:
08:36:44,789 INFO [org.jboss.ejb3.JmxKernelAbstraction] persistence.units:ear=ejb3-trials-ear.ear,unitName=ejb3-trials-persistence
08:36:44,809 DEBUG [com.winterthur.jackpot.security.jacc.JackpotPolicyConfiguration.ejb3-trials-ear.ear] linkConfiguration, linkTo: ejb3-trials-ejb.jar
08:36:44,809 DEBUG [com.winterthur.jackpot.security.jacc.JackpotPolicyConfiguration.ejb3-trials-ejb.jar] commit
08:36:44,809 INFO [org.jboss.ejb3.EJB3Deployer] Deployed: file:/C:/eplatform/jboss/4.0/server/eplatform-development/tmp/deploy/tmp11029ejb3-trials-ear.ear-contents/ejb3-trials-ejb.jar
08:36:44,819 INFO [org.jboss.ejb3.JmxKernelAbstraction] installing MBean: persistence.units:ear=ejb3-trials-ear.ear,unitName=ejb3-trials-persistence with dependencies:
08:36:44,819 INFO [org.jboss.ejb3.JmxKernelAbstraction] jboss.jca:name=DefaultDS,service=ManagedConnectionFactory
08:36:44,849 INFO [org.hibernate.ejb.Ejb3Configuration] Processing PersistenceUnitInfo [
name: ejb3-trials-persistence
...]
08:36:44,859 INFO [org.hibernate.ejb.Ejb3Configuration] found EJB3 Entity bean: trail.entity.beans.Record
08:36:44,869 INFO [org.hibernate.ejb.Ejb3Configuration] found EJB3 Entity bean: trail.entity.beans.TimedRecord
08:36:44,869 INFO [org.hibernate.ejb.Ejb3Configuration] found EJB3 Entity bean: trail.entity.beans.Investor
08:36:44,869 INFO [org.hibernate.ejb.Ejb3Configuration] found EJB3 Entity bean: trail.entity.beans.Fund
08:36:44,869 WARN [org.hibernate.ejb.Ejb3Configuration] Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
08:36:44,899 INFO [org.hibernate.cfg.Configuration] Reading mappings from resource: META-INF/orm.xml
08:36:44,899 INFO [org.hibernate.ejb.Ejb3Configuration] [PersistenceUnit: ejb3-trials-persistence] no META-INF/orm.xml found
08:36:44,919 INFO [org.hibernate.cfg.AnnotationBinder] Binding entity from annotated class: trail.entity.beans.Record
08:36:44,919 INFO [org.hibernate.cfg.annotations.EntityBinder] Bind entity trail.entity.beans.Record on table record
08:36:44,959 INFO [org.hibernate.cfg.AnnotationBinder] Binding entity from annotated class: trail.entity.beans.TimedRecord
08:36:44,969 INFO [org.hibernate.cfg.AnnotationBinder] Binding entity from annotated class: trail.entity.beans.Investor
08:36:44,969 INFO [org.hibernate.cfg.annotations.EntityBinder] Bind entity trail.entity.beans.Investor on table investor
08:36:44,969 INFO [org.hibernate.cfg.AnnotationBinder] Binding entity from annotated class: trail.entity.beans.Fund
08:36:44,979 INFO [org.hibernate.cfg.annotations.EntityBinder] Bind entity trail.entity.beans.Fund on table FUND
08:36:45,089 INFO [org.hibernate.connection.ConnectionProviderFactory] Initializing connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
08:36:45,089 INFO [org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider] Using provided datasource
08:36:45,089 INFO [org.hibernate.cfg.SettingsFactory] RDBMS: DB2/SUN, version: SQL08022
08:36:45,089 INFO [org.hibernate.cfg.SettingsFactory] JDBC driver: IBM DB2 JDBC Universal Driver Architecture, version: 2.8.46
08:36:45,089 INFO [org.hibernate.dialect.Dialect] Using dialect: org.hibernate.dialect.FirebirdDialect
08:36:45,099 INFO [org.hibernate.transaction.TransactionFactoryFactory] Transaction strategy: org.hibernate.ejb.transaction.JoinableCMTTransactionFactory
08:36:45,099 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiating TransactionManagerLookup: org.hibernate.transaction.JBossTransactionManagerLookup
08:36:45,099 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] instantiated TransactionManagerLookup
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Automatic flush during beforeCompletion(): disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Automatic session close at end of transaction: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Scrollable result sets: enabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] JDBC3 getGeneratedKeys(): disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Connection release mode: auto
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Default batch fetch size: 1
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Generate SQL with comments: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Order SQL updates by primary key: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
08:36:45,099 INFO [org.hibernate.hql.ast.ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Query language substitutions: {}
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Second-level cache: enabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Query cache: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Cache provider: org.hibernate.cache.HashtableCacheProvider
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Optimize cache for minimal puts: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Structured second-level cache entries: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Statistics: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Deleted entity synthetic identifier rollback: disabled
08:36:45,099 INFO [org.hibernate.cfg.SettingsFactory] Default entity-mode: pojo
08:36:45,119 INFO [org.hibernate.impl.SessionFactoryImpl] building session factory
08:36:45,229 INFO [org.hibernate.impl.SessionFactoryObjectFactory] Not binding factory to JNDI, no JNDI name configured
08:36:45,240 INFO [org.hibernate.util.NamingHelper] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}
08:36:45,280 DEBUG [com.winterthur.jackpot.jboss.transport.Ejb3SubjectDelegationCheckInterceptor] Ejb3SubjectDelegationCheckInterceptor is enabled.
08:36:45,530 DEBUG [com.winterthur.jackpot.security.jacc.JackpotPolicyConfiguration.ejb3-trials-ejb.jar] addToUncheckedPolicy, p=(javax.security.jacc.EJBMethodPermission EntityCalculator getFunds,,)[*:getFunds()]
08:36:45,530 INFO [org.jboss.ejb3.EJBContainer] STARTED EJB: trail.entity.basic.EntityCalculator ejbName: EntityCalculator
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months