Done
https://jira.jboss.org/jira/browse/JBCACHE-1464
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202175#4202175
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202175
___
anonymous wrote :
|
| On another note, it would be great as well if one could make a bulk get, so
retrieving many Fqns in one call, I have the scenario where a client might want
20 data items from the server, 10 of those data items live on a remote cache.
Clients timeout is 5 seconds, now
Another scenario that can currently happen is this
T1 acquires lock
T1 Writes and attempts to read but times out and throws exception
T2 acquires lock
T2 Writes
T2 Reads but he will read T1s response (not 100% sure but I would say it would)
T1 Resets the socket
Now if an app starts returning w
I just dont like the way the input and output streams are essentially left
unprotected. The fact that you can use the old outputstream and with the call
for read you can be using the new input stream, so what happens when that
scenario occurs??
T1 acquires lock
T2 waits
T1 throws exception
T2 n
Another approach could be to acquire the lock before invoking the operational
call in invokeWithRetries(). Still a bit coarse grained though.
Anyway, all this is due for redesign in the next major release, using a more
flexible and highly performant transport like Netty, MINA or XNIO. Actually
I don't rely on that lock. This assumes that the restart process will take a
while (a few seconds, maybe) so that other threads will get the lock on the
monitor, enter the sync block as well, and then also attempt to perform a
restart. And here is where they block (on restartComponent()) until
Actually...just thinking, i dont see where you are keeping hold of the
original write lock or am i not seeing something
T1 gets write lock
T2 waits for lock
T1 Throws exception
T2 acquires lock
T2 throws exception
T1 kicks off re-initialisation of component
T3 acquires lock
T3 writes but doe
Looks good..
Cheers Manik.
LL
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201854#4201854
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201854
___
jboss-user mailing
Hi there
Nope, you were looking at the wrong check-in. That doesn't contain the fix.
Have a look at this commit log.
Basically, I have delegated the restart process to a separate class, which
ensures that concurrent restarts do not happen, nor do "back-to-back" restarts.
It involves using a
Hi Manik,
Just seen your entry here to resolved
[
https://jira.jboss.org/jira/browse/JBCACHE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Had a look at your fix here
http://fisheye.jboss.org/browse/JBossCache/core/trunk/src/main/java/org/jboss/cache/loader/Tc
anonymous wrote :
| Problem is this, if we have a timeout,which the patch allows you to do, it
throws an IOExcpeption. When we get an IOEXception we will call "restart" which
tears down and up the socket even though its not needed. We shouldnt be tearing
up and down the socket if we timeout.
"lovelyliatroim" wrote : anonymous wrote :
| | No reason, really. Happy to accept a patch, to make this configurable
using a cache loader property.
| |
|
| Created one for the 2.2.1.GA version
| https://jira.jboss.org/jira/browse/JBCACHE-1451
|
Hi Manik,
You might have to r
anonymous wrote :
| Yes, this is all a part of the planned overhaul to this code.
|
| I suppose a simplistic retry could make it into the next minor release
though. Feel like creating a JIRA?
|
Done.
https://jira.jboss.org/jira/browse/JBCACHE-1457
View the original post :
http://w
Yes, this is all a part of the planned overhaul to this code.
I suppose a simplistic retry could make it into the next minor release though.
Feel like creating a JIRA?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199529#4199529
Reply to the post :
http:/
Just a comment on the TcpCacheServer as well.
I dont like this
| Thread serverThread = new Thread("TcpCacheServer")
| {
| @Override
| public void run()
| {
| try
| {
|while (running)
|{
|
anonymous wrote :
| Can you not simulate this in a test or staging environment, by loading one
server (which runs the TcpCacheServer) artificially (maybe even give it less
memory so it has to perform GC more often) and try and lock up the other
servers to get a thread dump?
|
Will try but
anonymous wrote :
| No reason, really. Happy to accept a patch, to make this configurable using
a cache loader property.
|
Created one for the 2.2.1.GA version
https://jira.jboss.org/jira/browse/JBCACHE-1451
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtop
"lovelyliatroim" wrote :
|
| Sorry didnt see this comment when I posted the last one. Where do i submit
patches to?? Is there a link on it??
|
|
There isn't one - you'll need to create a JIRA and attach it there.
View the original post :
http://www.jboss.com/index.html?module=bb&op=
Yeah, unfortunately without a proper thread dump it is hard to tell where the
problem is. Can you not simulate this in a test or staging environment, by
loading one server (which runs the TcpCacheServer) artificially (maybe even
give it less memory so it has to perform GC more often) and try an
anonymous wrote :
| No reason, really. Happy to accept a patch, to make this configurable using
a cache loader property.
|
Sorry didnt see this comment when I posted the last one. Where do i submit
patches to?? Is there a link on it??
Thanks,
LL
View the original post :
http://www.jbos
Reason im asking is this, i didnt have time yesterday to go into detail.
I ran some load tests on my app in a 3 node cluster. One node in particular
takes more of the load than the others and this node also hosts the
TcpCacheServer. After a while lets call it node3 ran into difficulties with GC
No reason, really. Happy to accept a patch, to make this configurable using a
cache loader property.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196812#4196812
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196812
22 matches
Mail list logo
