[Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent
by alesj
"dimitris(a)jboss.org" wrote : Why VFS::getCacheFile needs to be part of the API? One implementation could support caching, another one not.
Sure, hence my proposed change:
| Index: src/main/java/org/jboss/virtual/VFS.java
| ===================================================================
| --- src/main/java/org/jboss/virtual/VFS.java (revision 83078)
| +++ src/main/java/org/jboss/virtual/VFS.java (working copy)
| @@ -158,6 +158,20 @@
| }
|
| /**
| + * Create new root
| + *
| + * @param rootURI the root url
| + * @return the virtual file
| + * @throws IOException if there is a problem accessing the VFS
| + * @throws IllegalArgumentException if the rootURL
| + */
| + public static VirtualFile createNewRoot(URI rootURI) throws IOException
| + {
| + VFS vfs = getVFS(rootURI);
| + return vfs.getRoot();
| + }
| +
| + /**
| * Get the root virtual file
| *
| * @param rootURI the root uri
| @@ -167,8 +181,9 @@
| */
| public static VirtualFile getRoot(URI rootURI) throws IOException
| {
| - VFS vfs = getVFS(rootURI);
| - return vfs.getRoot();
| + VFSCache cache = VFSCacheFactory.getInstance();
| + VirtualFile file = cache.getFile(rootURI);
| + return (file != null) ? file : createNewRoot(rootURI);
| }
|
| /**
| @@ -182,12 +197,12 @@
| * @return the cached virtual file
| * @throws IOException for any error
| * @throws IllegalArgumentException if the rootURL is null
| + * @deprecated use getRoot
| */
| + @Deprecated
| public static VirtualFile getCachedFile(URI rootURI) throws IOException
| {
| - VFSCache cache = VFSCacheFactory.getInstance();
| - VirtualFile file = cache.getFile(rootURI);
| - return (file != null) ? file : getRoot(rootURI);
| + return getRoot(rootURI);
| }
|
| /**
| @@ -202,8 +217,8 @@
| @SuppressWarnings("deprecation")
| public static VirtualFile getVirtualFile(URI rootURI, String name) throws IOException
| {
| - VFS vfs = getVFS(rootURI);
| - return vfs.findChild(name);
| + VirtualFile root = getRoot(rootURI);
| + return root.findChild(name);
| }
|
| /**
| @@ -225,20 +240,35 @@
| }
|
| /**
| - * Get the root virtual file
| + * Create new root
| *
| * @param rootURL the root url
| * @return the virtual file
| * @throws IOException if there is a problem accessing the VFS
| * @throws IllegalArgumentException if the rootURL
| */
| - public static VirtualFile getRoot(URL rootURL) throws IOException
| + public static VirtualFile createNewRoot(URL rootURL) throws IOException
| {
| VFS vfs = getVFS(rootURL);
| return vfs.getRoot();
| }
|
| /**
| + * Get the root virtual file
| + *
| + * @param rootURL the root url
| + * @return the virtual file
| + * @throws IOException if there is a problem accessing the VFS
| + * @throws IllegalArgumentException if the rootURL
| + */
| + public static VirtualFile getRoot(URL rootURL) throws IOException
| + {
| + VFSCache cache = VFSCacheFactory.getInstance();
| + VirtualFile file = cache.getFile(rootURL);
| + return (file != null) ? file : createNewRoot(rootURL);
| + }
| +
| + /**
| * Get cached file.
| *
| * If VFSContext matching the rootURL parameter is cached
| @@ -249,12 +279,12 @@
| * @return the cached virtual file
| * @throws IOException for any error
| * @throws IllegalArgumentException if the rootURL is null
| + * @deprecated use getRoot
| */
| + @Deprecated
| public static VirtualFile getCachedFile(URL rootURL) throws IOException
| {
| - VFSCache cache = VFSCacheFactory.getInstance();
| - VirtualFile file = cache.getFile(rootURL);
| - return (file != null) ? file : getRoot(rootURL);
| + return getRoot(rootURL);
| }
|
| /**
| @@ -269,8 +299,8 @@
| @SuppressWarnings("deprecation")
| public static VirtualFile getVirtualFile(URL rootURL, String name) throws IOException
| {
| - VFS vfs = getVFS(rootURL);
| - return vfs.findChild(name);
| + VirtualFile root = getRoot(rootURL);
| + return root.findChild(name);
| }
|
| /**
|
So, in non-cached env, createNewRoot == getRoot.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203988#4203988
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203988
17 years, 2 months
[Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent
by alesj
"dimitris(a)jboss.org" wrote :
| From the outside I understand that caching should be an internal implementation detail/optimization non visible to the standard user or accessible over the simplified api.
|
What can be more simple than VFS::getCacheFile? :-)
"dimitris(a)jboss.org" wrote :
| Before we had URLs, everybody knew how they worked, server was working, there was nothing to configure, everyone was happy. With VFS we have started talking about cashing and weird options, and locking problems and threads and reapers and timeouts and what not. This is a step back, not forward. Some of it might be necessary, but it should be mostly invisible to the end user.
|
Afaik, this was all there before.
My guess is, it was just scattered all over the place, hence you didn't notice it.
Reading Adrian's CL history overview supports my 'theory':
- http://www.jboss.org/community/docs/DOC-13267
"adrian(a)jboss.org" wrote :
| A major motivation for this change is to move the handling of the file locking problems (seen on Windows) or file handle leaks (seen on Linux) into one place.
|
;-)
"dimitris(a)jboss.org" wrote :
| The whole point is: we need to make it *simpler*. It has to be stable and fast for 80% of the cases. Our users shouldn't even know it exists - they shouldn't care and they shouldn't have to tinker with bean descriptors to make it work for them, except for rare circumstances.
|
Unfortunately we only learn the details by examples.
But that's called OSS and community feedback. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203967#4203967
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203967
17 years, 2 months
[Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent
by alesj
Moving Dimitris' comment here.
"dimitris(a)jboss.org" wrote :
| From the outside I understand that caching should be an internal implementation detail/optimization non visible to the standard user or accessible over the simplified api.
|
| Before we had URLs, everybody knew how they worked, server was working, there was nothing to configure, everyone was happy. With VFS we have started talking about cashing and weird options, and locking problems and threads and reapers and timeouts and what not. This is a step back, not forward. Some of it might be necessary, but it should be mostly invisible to the end user.
|
| The whole point is: we need to make it *simpler*. It has to be stable and fast for 80% of the cases. Our users shouldn't even know it exists - they shouldn't care and they shouldn't have to tinker with bean descriptors to make it work for them, except for rare circumstances.
|
| That would make a successful design.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203965#4203965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203965
17 years, 2 months
[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics
by jhalliday
OK, JBTM-474 seems to have helped somewhat. There is still an issue with some of the JCA tests[1] that use the following cleanup code:
if (!TxUtils.isCompleted(tm))
{
tm.rollback();
fail("Tx was still active");
}
rollback is called, which is correct - it's needed to ensure thread disassociation. Note that the test is broken even for the JTA case, since there may be a complete tx associated to the thread and the rollback call is needed to disassociate it even if it's already rolled back. But in the JTS case since it can't determine the tx rolled back, rollback throws an exception rather than silently working as the JTA version does.
The issue here is that a timedout JTS tx is removed at the point it times out so thereafter its status cannot be determined. For some use cases (where the client and server are collocated) we could cache the outcome at the point the tx is removed, allowing getStatus and rollback|commit to behave more similarly to the JTA version.
But that won't work in distributed cases, since the tx is remote which means we either need it to hang around as long as a client has a handle on it (i.e. it's a distributed gc problem) or we need to notify all the clients of the outcome when it terminates (i.e. communication overhead). Neither of these appeal.
Thus the JCA test is going to have to change anyhow to cope with the distributed case.
It seems to me that what the test is really in interested in is: did the tx timeout as expected. It could either register a sync and use that to set a status flag, or rely on !isActive() rather than !isCompleted. Either way it needs an exception handler around tm.rollback, since that call is going to throw an exception.
[1] org.jboss.test.jca.test.TxConnectionManagerUnitTestCase
methods testSynchronizationAfterCompletionTxTimeout
testGetManagedConnectionTimeoutTrackByTx
testGetManagedConnectionTimeout
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203961#4203961
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203961
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Some comments on Clebert's last commit
by timfox
1) Forcing depage. I don't get this. Looking at the code I can see you force a depage if the reference isn't found in the queue
a) I notice you only force one depage - How can you be sure the required message is in the next page? It might be in any page after that.
b) Let's say you force a depage and the message *is* in there, the message will get depaged and routed to the queue. I can't see anywhere where the reference is then removed from the queue. Could this lead to duplicate deliveries?
2) Address is being passed on replicate delivery mesage. This worries me for performance reasons. Can't we do this another way?
3) Precalculation of flow control
a) if ((creditsUsed -= chunk.getRequiredBufferSize()) < 0)
Looks suspicious - this will actually decrement the creditsUsed variable
b) Can you be sure that the first large message chunk gets sent iirespective or available credits? - we need to ensure this to avoid blocking
c) pre-calculation of credits seems very complex... looks like it could do with some optimisation
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203909#4203909
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203909
17 years, 2 months