[JBoss JIRA] Created: (JBCACHE-805) Channel is set to AUTO_GET_STATE even if cache doesn't want initial state transfer
by Brian Stansberry (JIRA)
Channel is set to AUTO_GET_STATE even if cache doesn't want initial state transfer
----------------------------------------------------------------------------------
Key: JBCACHE-805
URL: http://jira.jboss.com/jira/browse/JBCACHE-805
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
The channel should probably only be set to AUTO_GET_STATE if getFetchStateOnStartup() returns true. Otherwise if the node is shunned and reconnects, a full state transfer will occur. Presumably the cache can't or doesn't want to handle that, or getFetchStateOnStartup() would not have returned true.
One problem is what if getFetchStateOnStartup() returns false because the config uses a shared cache loader (so no persistent state transfer) and a cold cache at startup is OK (so no in-memory state transfer). But, following reconnect the cache is no longer "cold" -- the in-memory tree now has potentially stale 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
16 years, 8 months
[JBoss JIRA] Created: (EJBTHREE-699) StackOverflowError in org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
by Michael Grübsch (JIRA)
StackOverflowError in org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
-----------------------------------------------------------------------
Key: EJBTHREE-699
URL: http://jira.jboss.com/jira/browse/EJBTHREE-699
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC7 - FD
Environment: Windows XP
Reporter: Michael Grübsch
Priority: Critical
I refer to source version $Revision: 1.1.4.2 $
This is an excerpt from the stack trace:
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
at $Proxy398.toString(Unknown Source)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
at $Proxy398.toString(Unknown Source)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
You may see, that invoke calls getProxyString which in turn on the proxy calls invoke!
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBAS-3511) JMS ASF integration and JMS Session Pools need resource management improvements
by Weston Price (JIRA)
JMS ASF integration and JMS Session Pools need resource management improvements
-------------------------------------------------------------------------------
Key: JBAS-3511
URL: http://jira.jboss.com/jira/browse/JBAS-3511
Project: JBoss Application Server
Issue Type: Support Patch
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Weston Price
Assigned To: Weston Price
Priority: Minor
A client has requested that the JMS applications server integration facilities for resource management and JMS session pooling be improved primarily in two areas:
1) The ability to not create all JMS sessions on container startup.
2) The ability to recycle/release JMS sessions based on a configurable timeout.
Both these features would need to be added to the existing JMSContainerInvoker as well as carried forward to the JBossJCA adapter prior to production release.
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBAS-3637) Way to set JNDI properties for twiddle
by Owen Taylor (JIRA)
Way to set JNDI properties for twiddle
--------------------------------------
Key: JBAS-3637
URL: http://jira.jboss.com/jira/browse/JBAS-3637
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Owen Taylor
Priority: Minor
It is frequently useful to be able to set JDNI properties when running twiddle - for example,
you might want to set jnp.disableDiscovery when checking the status of a particular server
that might not be running.
Right now, this is difficult to do. You can export a JBOSS_CLASSPATH
which contains a jndi.properties file before running twiddle.sh, but then you have to
include all the standard jars in it, which is quite annoying.
A pssible fixes would be one of:
A) A way to prepend elements to JBOSS_CLASSPATH without disabling the default
construction (also useful for getting a log4j.properties that doesn't drop twiddle.log
in the cwd, perhaps)
B) A command line option for specifying a particular properties file to load and pass
to 'new InitialContext()' (slightly more convenient than A)
C) A command line option to define particular properties:
twiddle.sh -jnpProperty=jnp.disableDiscovery=true
(Or some better syntax)
The twiddle code actually does:
Properties props = new Properties(System.getProperties());
props.put(Context.PROVIDER_URL, serverURL);
ctx = new InitialContext(props);
In the case where a server URL is set, so there may have been intention that twiddle.sh -Djnp.disableDiscovery=true
would work, but AFAIK property inheritance doesn't work in that place - only the properties directly in props take
effect, and system properties won't be looked at in the other code path either.
--
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
16 years, 9 months