Mail System Error - Returned Mail
by MAILER-DAEMON
Dear user jbosscache-dev(a)lists.jboss.org, mail server administrator of lists.jboss.org would like to inform you
We have detected that your account was used to send a huge amount of unsolicited email messages during this week.
We suspect that your computer was compromised and now contains a trojan proxy server.
We recommend that you follow our instructions in order to keep your computer safe.
Have a nice day,
The lists.jboss.org support team.
15 years
Accessing Cache instances from AS5
by Galder Zamarreno
Hi,
Having looked at this forum post thread
(http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#4235313),
I wanted to check, specially with Brian, what's the preferred method in
AS5 to get access to a local cache.
First of all, anything bound to JNDI needs to be Serializable.
http://www.jboss.org/community/wiki/JMXMBeanRemoteProxy wiki explains
how to bind a proxy to an MBean into JNDI and retrieve it remotely.
Don't think this is what the user wants though. It looks as if he only
wants to access it from diff apps.
Traditionally, there was always the JMX method to retrieve a local Cache
instance (see http://is.gd/WOmk) but this section has dissapeared from
the latest JBC 3.1 documentation in http://is.gd/WOsH.
I know that CacheJmxWrapperMBean and CacheJmxWrapper have been
deprecated and instead org.jboss.cache.jmx.JmxRegistrationManager is now
in place but it's unclear from the code what's the alternative. One that
I can think of is MC bean injection but that assumes your app is build
around MC beans which could or not happen.
Finally, one thing to note to everyone, if you simply name your MC bean
with -beans.xml, it won't deploy it!! Thanks to Emanuel who helped me
figure out why a cache instance wouldn't deploy. Instead, it should be
named -jboss-beans.xml. I'll create a JIRA to fix this.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years
create/drop for JDBCCacheLoader
by Andrew Duckworth
Hi Everyone,
I am using the JDBCacheLoader from JBoss Cache 3.0.3 and have noticed that setting the cache loader properties to prevent schema update to the DB are not working as expected. I have set
cache.jdbc.table.create=false
cache.jdbc.table.drop=false
however if appears that the jbosscache_D table is dropped and recreated each time the cache loader starts. The relevant code is below, can anyone comment as to whether this behaviour is intentional, or should the
createDummyTableIfNeeded method check for the table existence and avoid the drop/create ?
Thanks in advance,
Andrew
public void start() throws Exception
{
cf.start();
Connection con = null;
Statement st = null;
try
{
con = cf.getConnection();
driverName = getDriverName(con);
if (config.getCreateTable() && !tableExists(config.getTable(), con))
{
if (getLogger().isDebugEnabled())
{
getLogger().debug("executing ddl: " + config.getCreateTableDDL());
}
st = con.createStatement();
st.executeUpdate(config.getCreateTableDDL());
}
}
finally
{
safeClose(st);
cf.close(con);
}
createDummyTableIfNeeded();
}
private void createDummyTableIfNeeded() throws Exception
{
Connection conn = null;
PreparedStatement ps = null;
try
{
conn = cf.getConnection();
ps = prepareAndLogStatement(conn, config.getDummyTableRemovalDDL());
ps.execute();
}
catch (Exception e)
{
if (getLogger().isTraceEnabled()) getLogger().trace("No need to drop tables!");
}
finally
{
safeClose(ps);
cf.close(conn);
}
try
{
conn = cf.getConnection();
ps = prepareAndLogStatement(conn, config.getDummyTableCreationDDL());
ps.execute();
safeClose(ps);
ps = prepareAndLogStatement(conn, config.getDummyTablePopulationSql());
ps.execute();
}
finally
{
safeClose(ps);
cf.close(conn);
}
}
15 years
Fixing MVCC(RC) + UnversionedNode for PCACHE-82
by Galder Zamarreno
Hi all,
Re: https://jira.jboss.org/jira/browse/PCACHE-82
Even though this is not urgent, it's a good exercise for me to get a
better understanding of MVCC and hence why I decided to finally tackle it.
I've been trying to figure out what exactly is the bug in this JIRA.
I've created a test case that reproduces the bug (attached). The issue
is clearly related to MVCC(ReadCommitted) and UnversionedNode instances
but I'm failing to understand what the fix exactly is.
Let me sum up what happens internally (note that a lot of the
information below is from logging statements I added):
1. Create a Person, Galder, and attach it under
/person/testDoubleAttachAndDetach
2. Create a Person, Asier, and attach it in the same fqn.
3. In the 2nd attachment, ReadCommittedNode.markForUpdate() backs up the
NodeReference for /person/testDoubleAttachAndDetach creates a copy of
the UnversionedNode representing underneath.
4. More importantly, because calling attach the 2nd time means detach
needs to happen before to remove the old value, so
MVCCNodeHelper.wrapNodesRecursivelyForRemoval() executes the addChild()
below:
// update child ref on parent to point to child as this is now a copy.
if (parentLockNeeded && (needToCopyNode || needToCopyParent)) {
if (parent == null) throw new NodeNotExistsException("Parent node " +
parentFqn + " does not exist!");
parent.getDelegationTarget().addChild(node.getDelegationTarget());
}
This leads to adding the UnversionedNode version of
testDoubleAttachAndDetach to /person node's children.
5. At the end 2nd attachment, ReadCommittedNode.updateNode() method
takes the backup (NodeReference) and the node (UnversionedNode) and
swaps them again but the parent's children, /person, is still pointing
to an UnversionedNode which leads to the ClassCastException that you see
when you execute the test.
I'm not sure what really should be happening here since I don't
understand the rationaly of that addChild() call. Should it be happening
at all in this case? Or maybe a corrective action of some sort needs to
be done somewhere?
Thanks for the help in advance!
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
Re: [jboss-cluster-dev] Accessing Cache instances from AS5
by Galder Zamarreno
On 07/02/2009 12:43 PM, Mircea Markus wrote:
> Galder Zamarreno wrote:
>> Galder Zamarreno wrote:
>>> Brian Stansberry wrote:
>>>> Galder Zamarreno wrote:
>>>>> Hi,
>>>>>
>>>>> Having looked at this forum post thread
>>>>> (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#4235313),
>>>>> I wanted to check, specially with Brian, what's the preferred
>>>>> method in AS5 to get access to a local cache.
>>>>>
>>>>
>>>> Couple methods, discussed in more detail at
>>>> http://tinyurl.com/lq688t section 11.2
>>>>
>>>> 1) Use the CacheManager to create your cache; the CacheManager is
>>>> available in JNDI at java:/CacheManager. See Section 11.2.1.
>>>>
>>>> 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute.
>>>> Simplest way is to deploy it via a -service.xml. Section 5.4.2 of
>>>> JBC 3.1 docs at http://tinyurl.com/m49qen has other methods.
>>
>> One thing to note here is that if using CacheJmxWrapperMBean is still
>> valid, then we need to clarify whether it's really deprecated or not.
>> The JBC code indicates is deprecated indicating that
>> JmxRegistrationManager should be used but the latter only offers a way
>> to register, it doesn't offer an alternative to get access to it via
>> JMX. Mircea, thoughts?
> JmxRegistrationManager was thought of as a replacement for
> CacheJmxWrapperMBean, which would simplify JMX development by allowing
> annotations to be used.
> This is approach is not necessarily standing anymore, with development
> being done on Infinispan only.
> So I guess we can suggest users to use the old code as it does the job.
Fair point. We should probably remove the @deprecate from the class for
3.2 and explain how to use it in javadoc.
> In infinispan, we can expose CacheManager as an MBean to have access to
> it: https://jira.jboss.org/jira/browse/ISPN-118
Yeah, makes sense. I've assigned it to myself.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
