Re: [collections] LRUMap Problem ConcurrentModificationException
OK so my search will continue :-)
Meanwhile I'll consider to change my implementation, which i'd like to
prevent.
Maybe somebody of you knows a time and size based cache system where i can
map a key to an object?
René
2009/6/16 Otis Gospodnetic otis_gospodne...@yahoo.com
That's the one, René. Yeah, no real solution in that JIRA issue I'm
afraid. :( But it shows you what's already been looked at.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Renè Glanzer rene.glan...@gmail.com
To: Commons Users List user@commons.apache.org
Sent: Tuesday, June 16, 2009 6:05:26 AM
Subject: Re: [collections] LRUMap Problem ConcurrentModificationException
Hey Otis,
i found this one:
https://issues.apache.org/jira/browse/COLLECTIONS-3
but there is no solutions only an assumption at the end of the thread??
René
2009/6/15 Otis Gospodnetic :
Btw. I think you'll find a report about this from a few years ago in
the
Collections JIRA. Just search for my name.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Renè Glanzer
To: Commons Users List
Sent: Monday, June 15, 2009 12:00:54 PM
Subject: Re: [collections] LRUMap Problem
ConcurrentModificationException
Yes of course,
the code with the time based cache systems was set up with an ordniary
HashMap. But when rapidly seach requests are
generated the time based mechanism fails to delete old entries - cause
they are not old enough - and so the cache will
raise up until the entire VM memory is used. Then i found the LRUMap
switched to it and bang Exception in my delete method.
When i switch back to HashMap the code runs well - as currently on the
productive system - except the open memory leak.
René
2009/6/15 Leon Rosenberg :
just out of curiosity have you tried the same code with a standard
hashmap?
Leon
On Mon, Jun 15, 2009 at 4:37 PM, Renè Glanzerwrote:
Hello,
side note accepted :-)
In my class I checked the get, put and remove methods. All are
synchronized.
As you can see also the code which wants to delete the elements is
synchronized.
So I've no clue where the ConcurrentModificationException is
comming
from
:-(
Thanks René
2009/6/15 Leon Rosenberg :
Hello,
on a side note, generics make reading of code easier :-)
you haven't posted the whole code, but have you (double)checked
that
all other acesses to store are synchronized?
regards
Leon
On Mon, Jun 15, 2009 at 2:31 PM, Renè Glanzerwrote:
I'm calling the remove() method on the iterator. I know when i
call
the remove on the map itself it will cause the problem with my
currently running iterator, but i'm aware of that.
Here is the code block which should delete old entries:
store: is the LRUMap
birth: is a long which keeps the creation time when this is set
to 0
the item should be deleted
public void removeAllExpiredItems()
{
synchronized(this.store)
{
Iterator it=this.store.keySet().iterator();
while(it.hasNext())
{
Object key=it.next();
Object o=this.get(key);
if(o != null)
{
Item iEntry=(Item)this.store.get(key);
if(iEntry.birth==0)
it.remove(); //Here the exception occurs
}
}
this.setLastCleanDate(new Date()); //only to know when the
deleter run the last time
}
}
Thanks for any help :-)
René
2009/6/15 James Carman :
Are you calling remove() on the iterator or on the map itself?
On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer
wrote:
Hello,
is there still no help for me?
Is somebody able to explain me, why i get this
java.util.ConcurrentModificationException
on iterating and calling remove() on the LRUMap?
Please
René
2009/6/10 Renè Glanzer :
Hello Ted,
thanks for the fast response. I understand that simultaneously
puts
and gets do not cause the exception cause they are
synchronized in my
class.
And my stated code-fragment is the part which wants to delete
the
entries from the underlying LRUMap. And my code is wrapped in
the
synchronized block. But i think the LRUMap herselfe also
iterates the
entries and this maybe happens at the same time when my
iterator is
checking and trying to delete elements. My class is not
implementing
the LRUMap but has one LRUMap as a variable.
So your solution to override the removeLRU(Entry) methode
would not
help meunfortunatelly :-(
For now i really do not know how to solve the problem in an
easy way
without refractoring the entire code?
Any other solutions?
Thanks René
Re: [collections] LRUMap Problem ConcurrentModificationException
Hi Renè, Renè Glanzer wrote at Mittwoch, 17. Juni 2009 09:47: OK so my search will continue :-) Meanwhile I'll consider to change my implementation, which i'd like to prevent. I've reopened COLLECTIONS-3, since I was able to write a unit test that reproduces the problem. Maybe somebody of you knows a time and size based cache system where i can map a key to an object? My enhancement of the unit test for the LRUMap shows, that the ConcurrentModificationException only happens, if you use an iterator form the keySet. So you should simply use the entrySet in your code and you'll be fine. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Hi Jörg, that are great news, I'll give it a try. And of course I'll report my experience. René 2009/6/17 Jörg Schaible joerg.schai...@gmx.de Hi Renè, Renè Glanzer wrote at Mittwoch, 17. Juni 2009 09:47: OK so my search will continue :-) Meanwhile I'll consider to change my implementation, which i'd like to prevent. I've reopened COLLECTIONS-3, since I was able to write a unit test that reproduces the problem. Maybe somebody of you knows a time and size based cache system where i can map a key to an object? My enhancement of the unit test for the LRUMap shows, that the ConcurrentModificationException only happens, if you use an iterator form the keySet. So you should simply use the entrySet in your code and you'll be fine. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48: Hi Jörg, that are great news, I'll give it a try. And of course I'll report my experience. That would be fine. Actually I opened an own JIRA issue for this now (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long history of different symptoms. - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Hi Jörg,
it's me again. With a smile on my face :-)
I changed my code according to your hint.
Now i don't use the keySet but the entrySet. With only to adopt the rest of
the method to the entrySet and still
calling the remove() method of the iterator in my tests no
ConcurrentModificationException occured!!
Additionally now I'm using the LURMap.mapIterator() which also performs well
and according to the docu should be prefered over the entrySet or keySet.
Now the new an well working code looks like this:
public void removeAllExpiredItems()
{
synchronized(this.store)
{
MapIterator it=this.store.mapIterator(); //Here I'm using the new
MapIterator
while(it.hasNext())
{
m_catLog.debug(Reading object);
Object key=it.next();
Item currentItem=(Item)it.getValue();
if(currentItem.birth==0)
{
m_catLog.debug(0 birth found for key +key+ calling
Iterator.remove);
it.remove();
}
}
this.setLastCleanDate(new Date());
}
}
Thousand Thanks for your help Jörg
this fixed my Problem and maybe also fixes the problems from the other
people who suffered the same problem.
Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
handling the problem with the keySet call.
2009/6/17 Jörg Schaible joerg.schai...@gmx.de
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
Hi Jörg,
that are great news, I'll give it a try.
And of course I'll report my experience.
That would be fine. Actually I opened an own JIRA issue for this now
(COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
history of different symptoms.
- Jörg
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Hi,
it's me again with an update.
the LRUMap.mapIterator() still produces the
ConcurrentModificationException when a call to MapIterator.remove()
occurs.
Maybe this info helps
René
2009/6/17 Renè Glanzer rene.glan...@gmail.com:
Hi Jörg,
it's me again. With a smile on my face :-)
I changed my code according to your hint.
Now i don't use the keySet but the entrySet. With only to adopt the rest of
the method to the entrySet and still
calling the remove() method of the iterator in my tests no
ConcurrentModificationException occured!!
Additionally now I'm using the LURMap.mapIterator() which also performs well
and according to the docu should be prefered over the entrySet or keySet.
Now the new an well working code looks like this:
public void removeAllExpiredItems()
{
synchronized(this.store)
{
MapIterator it=this.store.mapIterator(); //Here I'm using the new
MapIterator
while(it.hasNext())
{
m_catLog.debug(Reading object);
Object key=it.next();
Item currentItem=(Item)it.getValue();
if(currentItem.birth==0)
{
m_catLog.debug(0 birth found for key +key+ calling
Iterator.remove);
it.remove();
}
}
this.setLastCleanDate(new Date());
}
}
Thousand Thanks for your help Jörg
this fixed my Problem and maybe also fixes the problems from the other
people who suffered the same problem.
Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
handling the problem with the keySet call.
2009/6/17 Jörg Schaible joerg.schai...@gmx.de
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
Hi Jörg,
that are great news, I'll give it a try.
And of course I'll report my experience.
That would be fine. Actually I opened an own JIRA issue for this now
(COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
history of different symptoms.
- Jörg
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
why don't you just use softreference + expiration timestamp and save
all the trouble?
Leon
On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzerrene.glan...@gmail.com wrote:
Hi,
it's me again with an update.
the LRUMap.mapIterator() still produces the
ConcurrentModificationException when a call to MapIterator.remove()
occurs.
Maybe this info helps
René
2009/6/17 Renè Glanzer rene.glan...@gmail.com:
Hi Jörg,
it's me again. With a smile on my face :-)
I changed my code according to your hint.
Now i don't use the keySet but the entrySet. With only to adopt the rest of
the method to the entrySet and still
calling the remove() method of the iterator in my tests no
ConcurrentModificationException occured!!
Additionally now I'm using the LURMap.mapIterator() which also performs well
and according to the docu should be prefered over the entrySet or keySet.
Now the new an well working code looks like this:
public void removeAllExpiredItems()
{
synchronized(this.store)
{
MapIterator it=this.store.mapIterator(); //Here I'm using the new
MapIterator
while(it.hasNext())
{
m_catLog.debug(Reading object);
Object key=it.next();
Item currentItem=(Item)it.getValue();
if(currentItem.birth==0)
{
m_catLog.debug(0 birth found for key +key+ calling
Iterator.remove);
it.remove();
}
}
this.setLastCleanDate(new Date());
}
}
Thousand Thanks for your help Jörg
this fixed my Problem and maybe also fixes the problems from the other
people who suffered the same problem.
Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
handling the problem with the keySet call.
2009/6/17 Jörg Schaible joerg.schai...@gmx.de
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
Hi Jörg,
that are great news, I'll give it a try.
And of course I'll report my experience.
That would be fine. Actually I opened an own JIRA issue for this now
(COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
history of different symptoms.
- Jörg
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] some ways for storing the states, transitions and any hierarchical structure
Hi Nestor, Has there been any update you have on state persistence for scxml ? Regards, R2D2. Nestor Urquiza-3 wrote: Yes I will keep you posted and in fact I am evaluating to use iBATIC (I posted the question to javaranch, iBATIC and Hibernate forums) because seems like iBATIC creates columns per fields from objects which makes the reporting easy if the way of storing is consistent. However I really think that mysql 5.0 option is still a good one. I will wait for responses from the rest of the forums and I will be back with whatever approach I fillow and the results of course. Thanks --- Rahul Akolkar rahul.akol...@gmail.com wrote: While there may be subscribers to this list that are quite familiar with hibernate, I'd also suggest asking (the question below) on the hibernate lists since this seems more appropriate there. But I imagine this to be of interest to [scxml] users (it certainly is to me), so if you do get things set up the way you want with hibernate and are so inclined, please feel free to add a page to our wiki [1] so it becomes commons knowledge. Thanks, -Rahul [1] http://wiki.apache.org/jakarta-commons/SCXML/HomePage On 5/8/06, Nestor Urquiza nest...@yahoo.com wrote: I have to decide for my project if it is worth it to store some of my objects directly in mysql using Hibernate. The usecase is just a web application accepting HTTP GET/POST requests and depending on given states it executes some code and move the client to a new state (I am using commons-scxml [1] for this). Moving from a starting state to an ending state the application pass several internal states and I need to store the whole history in a table. I could use mysql 5 UpdateXML() extractValue() UDF functions to store/retrieve the hierarchical data but as an alternative I think storing objects directly is a perfect approach. In fact I think ORM is a pretty cool alternative to native xml storage. The real problem arrives when Reporting guys want to query the mysql database for the states I have stored using Hibernate. I saw from Hibernate Tools there is a console plugin for eclipse [2] that allows to query the database using HSQL, however I am wondering if anyone knows about a way of using just plain SQL from a mysql client to query data that is stored using Hibernate. I understand this could be done using an UDF (User Defined Function). Any thoughts? Whatever idea you might have could help a lot my storage options/decision. Thanks a lot!, Nestor Urquiza [1] http://jakarta.apache.org/commons/scxml/ [2] http://www.hibernate.org/255.html - To unsubscribe, e-mail: commons-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: commons-user-h...@jakarta.apache.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: commons-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: commons-user-h...@jakarta.apache.org -- View this message in context: http://www.nabble.com/-scxml--some-ways-for-storing-the-states%2C-transitions-and-any-hierarchical-structure-tp4282259p24074766.html Sent from the Commons - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[SCXML] state persistence with failure recovery
Hi all, is it possible to persist the state of an scxml instance into a database ? What would be the api call structure to achieve this? I understand that the junits have roundtrip testcase to check for serialization and deserialization. However, file system based operations are not currently envisaged. I am looking at the 0.9 release of commons-scxml. Further, I have a custom eventing framework and would like to use this within the scxml state machine so that all calls to fireEvent are going to create and emit a custom event which would cause a transition to be taken for a statechart instance. The initial requirement of persisting the state to a database is given a failure scenario when post restart the statechart instance needs to be in a particular wait state and awaiting action(input event fired to it) so that the next state(if not a 'final' state) can be transitioned to. Regards, R2D2. -- View this message in context: http://www.nabble.com/-SCXML--state-persistence-with-failure-recovery-tp24075078p24075078.html Sent from the Commons - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Well, I hope your hash function is well thought through :-)
otherwise using hashmap for caching might be a mess
On Wed, Jun 17, 2009 at 4:30 PM, Renè Glanzerrene.glan...@gmail.com wrote:
I was searching for a very lighweight cache systems with not much overhead
for my purposes. The LRUMap just matched
perfectly except the little iterator problem.
2009/6/17 James Carman ja...@carmanconsulting.com
Or, ehcache or oscache or something like that?
On Wed, Jun 17, 2009 at 10:17 AM, Leon
Rosenbergrosenberg.l...@googlemail.com wrote:
why don't you just use softreference + expiration timestamp and save
all the trouble?
Leon
On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzerrene.glan...@gmail.com
wrote:
Hi,
it's me again with an update.
the LRUMap.mapIterator() still produces the
ConcurrentModificationException when a call to MapIterator.remove()
occurs.
Maybe this info helps
René
2009/6/17 Renè Glanzer rene.glan...@gmail.com:
Hi Jörg,
it's me again. With a smile on my face :-)
I changed my code according to your hint.
Now i don't use the keySet but the entrySet. With only to adopt the
rest of
the method to the entrySet and still
calling the remove() method of the iterator in my tests no
ConcurrentModificationException occured!!
Additionally now I'm using the LURMap.mapIterator() which also performs
well
and according to the docu should be prefered over the entrySet or
keySet.
Now the new an well working code looks like this:
public void removeAllExpiredItems()
{
synchronized(this.store)
{
MapIterator it=this.store.mapIterator(); //Here I'm using the new
MapIterator
while(it.hasNext())
{
m_catLog.debug(Reading object);
Object key=it.next();
Item currentItem=(Item)it.getValue();
if(currentItem.birth==0)
{
m_catLog.debug(0 birth found for key +key+ calling
Iterator.remove);
it.remove();
}
}
this.setLastCleanDate(new Date());
}
}
Thousand Thanks for your help Jörg
this fixed my Problem and maybe also fixes the problems from the other
people who suffered the same problem.
Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
handling the problem with the keySet call.
2009/6/17 Jörg Schaible joerg.schai...@gmx.de
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
Hi Jörg,
that are great news, I'll give it a try.
And of course I'll report my experience.
That would be fine. Actually I opened an own JIRA issue for this now
(COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
history of different symptoms.
- Jörg
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 16:07: Hi, it's me again with an update. the LRUMap.mapIterator() still produces the ConcurrentModificationException when a call to MapIterator.remove() occurs. So did you also try with the entrySet? I've not written a unit test for the MapIterator, so I cannot say, what you should expect... :) - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
I only gave it a short test. Then i found the MapIterator in the docs an switched to it. The docs stated that MapIterator is the better way than entrySet. Sorry for this, I'm at home right now so i can test it with an entrySet at the earliest tomorrow. Looking forward to report the result. 2009/6/17 Jörg Schaible joerg.schai...@gmx.de Renè Glanzer wrote at Mittwoch, 17. Juni 2009 16:07: Hi, it's me again with an update. the LRUMap.mapIterator() still produces the ConcurrentModificationException when a call to MapIterator.remove() occurs. So did you also try with the entrySet? I've not written a unit test for the MapIterator, so I cannot say, what you should expect... :) - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
