9:31 a.m.
We are in the 3rd week of delay for the JBossAS 5.0.1.GA release and there is still no
indication of where this will end.
- We are still on snapshots
<version.org.jboss.vfs>2.2.0-SNAPSHOT</version.org.jboss.vfs>
<version.org.jboss.microcontainer>2.2.0-SNAPSHOT</version.org.jboss.microcontainer>
<version.org.jboss.cl>2.0.3-SNAPSHOT</version.org.jboss.cl>
<version.org.jboss.deployers>2.2.0-SNAPSHOT</version.org.jboss.deployers>
<version.seam.integration>5.2.0-SNAPSHOT</version.seam.integration>
- Every updated snapshot solves some issue but introduces another regression.
The latest ones:
https://jira.jboss.org/jira/browse/JBAS-6513
https://jira.jboss.org/jira/browse/JBCTS-900
- Although we keep closing issues, the number of JIRA tasks remains constant for the past
few weeks (4-10 open issues)
I know we want to time-box but for this particular release it doesn't make sense to me
to
release unless we fix vfs, which was the biggest issue, anyway.
What is going so wrong with VFS and how we can fix it?
All opinions are welcome.
/D
9:51 a.m.
On 02/17/2009 09:31 AM, Dimitris Andreadis wrote:
We are in the 3rd week of delay for the JBossAS 5.0.1.GA release and
there is still no indication of where this will end.
- We are still on snapshots
- Every updated snapshot solves some issue but introduces another
regression.
Maybe we should consider going back to the most stable prior release for
these? The point of doing micro releases is NOT to fix every known bug in
every release IMHO. These ought to be time-boxed (well, as much as
possible) as well. There has to have been a lot of good bug fixes by now.
And we can always do a 5.0.2 - who knows, the community might start to
think we really ARE releasing often :-)
- DML
9:53 a.m.
- Every updated snapshot solves some issue but introduces another
regression.
The problem is that the initial issue - deleting files that result from
nested jars -
actually unfortunately turned into "opening a can of worms". :-(
Timeline:
(1) deleting unjared nested jars
(2) how we actually handle/understand all temps + cache
(3) how we handle temps in Deployers
(4) fix how we handle this in AbstractWarDeployer
(5) moving hasDeploymentBeenModified in JBossAS
* moving it into Deployers
* actually understanding temp notion
(6) treating temps as originals via URL/URI
(7) deleting temps breaks re-deploy
(8) ... :-(
What is going so wrong with VFS and how we can fix it?
VFS even w/o temps and cache notion is not so trivial.
If you add temps and the actual caching (to get Seam deployment under
10min ;-),
you'll see where all can go wrong.
e.g. with some TCK tests and (6) it was such a small detail as '/' at
the end of URI.
Take this example and multiply it with X, to get the real picture on
what all could go wrong. ;-)
How to fix this?
Besides more tests in VFS?
Getting some more help to dig into those failure never hurt.
But I have a few other 'non testing' ideas.
But you already know about them, the question is are you gonna do
something about them. ;-)
9:56 a.m.
Dimitris,
I think we should wait till we have got all the vfs stuff done. This
is the first minor release after AS5GA. All of us are learning what
works - what does not work, which we can feed to the next minor release
(5.0.2) and later.
Dimitris Andreadis wrote:
We are in the 3rd week of delay for the JBossAS 5.0.1.GA release and
there is still no indication of where this will end.
- We are still on snapshots
<version.org.jboss.vfs>2.2.0-SNAPSHOT</version.org.jboss.vfs>
<version.org.jboss.microcontainer>2.2.0-SNAPSHOT</version.org.jboss.microcontainer>
<version.org.jboss.cl>2.0.3-SNAPSHOT</version.org.jboss.cl>
<version.org.jboss.deployers>2.2.0-SNAPSHOT</version.org.jboss.deployers>
<version.seam.integration>5.2.0-SNAPSHOT</version.seam.integration>
- Every updated snapshot solves some issue but introduces another
regression.
The latest ones:
https://jira.jboss.org/jira/browse/JBAS-6513
https://jira.jboss.org/jira/browse/JBCTS-900
- Although we keep closing issues, the number of JIRA tasks remains
constant for the past few weeks (4-10 open issues)
I know we want to time-box but for this particular release it doesn't
make sense to me to release unless we fix vfs, which was the biggest
issue, anyway.
What is going so wrong with VFS and how we can fix it?
All opinions are welcome.
/D
10:25 a.m.
On Tue, 2009-02-17 at 17:31 +0200, Dimitris Andreadis wrote:
This should be fixed with Ales's latest changes?
This is broken because of ...
On Tue, 2009-02-17 at 16:53 +0100, Ales Justin wrote:
e.g. with some TCK tests and (6) it was such a small detail as
'/' at
the end of URI.
The main reason I originally looked at the VFS code was because
it was unusable due to inconsistencies between paths (not URI/URLs)
that may or not may not end with a /
Sometimes they did and sometimes they didn't and it was very random
(even internally within the same VFS call).
I changed the code so that the internal VFS paths always used the
version without the trailing / which meant
1) It was always consistent
2) You didn't have to play around with complicated path matching
or string manipulation within the critical (i.e. potentially slow)
sections of the code.
This change
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/vfs/trunk/src...
and its current usage within the VFS make all that for nothing.
e.g. in DefaultVFSRegistry.getFile(URI)
VFSContext context = getCache().findContext(uri);
if (context != null)
{
// THIS ALWAYS ADD AS A / TO THE END OF THE PATH
// IT SHOULD NOT, ITS USED AS AN INTERNAL VFS PATH (SEE BELOW)
String relativePath = VFSUtils.getRelativePath(context, uri);
for (TempInfo ti : context.getTempInfos())
{
String path = ti.getPath();
if (relativePath.startsWith(path))
{
// THIS WILL FAIL BECAUSE OF THE / ON THE INTERNAL VFS PATH
// IT TRANSLATES TO root.getChild(path + "/")
String subpath = relativePath.substring(path.length());
VirtualFileHandler child = findHandler(ti.getHandler(),
subpath, true);
if (child != null)
return child.getVirtualFile();
}
}
If you include the URL <-> URI mapping in that code, its also likely to
be far too much string manipulation/searching to be performant under any
kind of load.
From the part of the stacktrace that is failing, there's at least
5
potentially expensive operations always performed.
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:107)
1) stripProtocol => StringBuffer construction
2) substring in VFSUtils.getRelativePath()
3) relativePath.startsWith()
4) relativePath.substring()
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:81)
at
5) URL -> URI mapping
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:119)
at
org.jboss.virtual.protocol.AbstractVFSHandler.openConnection(AbstractVFSHandler.java:71)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:33 a.m.
On Tue, 2009-02-17 at 17:25 +0100, Adrian Brock wrote:
On Tue, 2009-02-17 at 17:31 +0200, Dimitris Andreadis wrote:
> https://jira.jboss.org/jira/browse/JBCTS-900
>
This is broken because of ...
On Tue, 2009-02-17 at 16:53 +0100, Ales Justin wrote:
> e.g. with some TCK tests and (6) it was such a small detail as '/' at
> the end of URI.
<snip/>
This change
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/vfs/trunk/src...
and its current usage within the VFS make all that for nothing.
It was easy to figure out the problem was due to broken vfs paths
by looking at the error message and then working back through the
stacktrace:
java.io.IOException: Child not found /lib/common.jar/
<snip/>
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:107)
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:81)
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:119)
You can even see that adding the / wouldn't be valid if that path was
the URI/URL because from the previous log statement, it is not unpacked
and therefore not a directory.
"
Searching mapped entities in jar/par:
vfszip:snipped/ejb3_pkg_scope.jar/lib/common.jar
"
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:56 a.m.
> This change
>
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/vfs/trunk/src...
> and its current usage within the VFS make all that for nothing.
>
It was easy to figure out the problem was due to broken vfs paths
by looking at the error message and then working back through the
stacktrace:
java.io.IOException: Child not found /lib/common.jar/
<snip/>
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:107)
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:81)
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:119)
You can even see that adding the / wouldn't be valid if that path was
the URI/URL because from the previous log statement, it is not unpacked
and therefore not a directory.
"
Searching mapped entities in jar/par:
vfszip:snipped/ejb3_pkg_scope.jar/lib/common.jar
"
I don't think this is the problem.
"vfszip:snipped/ejb3_pkg_scope.jar/lib/common.jar" is broken in the
first place.
lib/common.jar is in .ear not .jar.
10:52 a.m.
On Tue, 2009-02-17 at 17:31 +0200, Dimitris Andreadis wrote:
> https://jira.jboss.org/jira/browse/JBAS-6513
This should be fixed with Ales's latest changes?
Just about to check.
> https://jira.jboss.org/jira/browse/JBCTS-900
>
This is broken because of ...
There is some weird URL construction.
The "lib/common.jar" is actually on .ear not on .jar.
No idea who constructs this ...
The main reason I originally looked at the VFS code was because
it was unusable due to inconsistencies between paths (not URI/URLs)
that may or not may not end with a /
Exactly.
I on the other hand ended up with some external things expecting "/" at
the end.
If I remember correctly it was Seam's Facelets stuff.
Hence I changed that every non-leaf ends with "/" to make it consistent.
Sometimes they did and sometimes they didn't and it was very
random
(even internally within the same VFS call).
Yup.
Some test had it some didn't.
I changed the code so that the internal VFS paths always used the
version without the trailing / which meant
1) It was always consistent
2) You didn't have to play around with complicated path matching
or string manipulation within the critical (i.e. potentially slow)
sections of the code.
I guess I can bring that back ...
This change
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/vfs/trunk/src...
and its current usage within the VFS make all that for nothing.
This can be changed as part of previous task.
e.g. in DefaultVFSRegistry.getFile(URI)
VFSContext context = getCache().findContext(uri);
if (context != null)
{
// THIS ALWAYS ADD AS A / TO THE END OF THE PATH
// IT SHOULD NOT, ITS USED AS AN INTERNAL VFS PATH (SEE BELOW)
String relativePath = VFSUtils.getRelativePath(context, uri);
for (TempInfo ti : context.getTempInfos())
{
String path = ti.getPath();
if (relativePath.startsWith(path))
{
// THIS WILL FAIL BECAUSE OF THE / ON THE INTERNAL VFS PATH
// IT TRANSLATES TO root.getChild(path + "/")
I don't think this will fail,
as we mostly check tokens not exact path.
(in StructuredVirtualFileHandler; which is 99% of VFS handlers)
String subpath =
relativePath.substring(path.length());
VirtualFileHandler child = findHandler(ti.getHandler(),
subpath, true);
if (child != null)
return child.getVirtualFile();
}
}
If you include the URL <-> URI mapping in that code, its also likely to
be far too much string manipulation/searching to be performant under any
kind of load.
How they say, impl first, optimize later? :-)
>From the part of the stacktrace that is failing, there's at
least 5
potentially expensive operations always performed.
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.findHandler(DefaultVFSRegistry.java:107)
1) stripProtocol => StringBuffer construction
2) substring in VFSUtils.getRelativePath()
3) relativePath.startsWith()
4) relativePath.substring()
at
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:81)
at
5) URL -> URI mapping
org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:119)
at
org.jboss.virtual.protocol.AbstractVFSHandler.openConnection(AbstractVFSHandler.java:71)
Again, part of optimization.
But I definitely agree, it should be changed.
11:03 a.m.
> On Tue, 2009-02-17 at 17:31 +0200, Dimitris Andreadis wrote:
>> https://jira.jboss.org/jira/browse/JBAS-6513
>
> This should be fixed with Ales's latest changes?
Just about to check.
C:\projects\branches\jbossas\Branch_5_0\testsuite>build one-test
-Dtest=org.jboss.test.hibernate.test.HibernateIntgUnitTestCase
Calling ..\tools\bin\ant.bat one-test -Dtest
org.jboss.test.hibernate.test.HibernateIntgUnitTestCase
Buildfile: build.xml
one-test:
[delete] Deleting:
C:\projects\branches\jbossas\Branch_5_0\testsuite\output\log\test.log
[junit] Running org.jboss.test.hibernate.test.HibernateIntgUnitTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6,782 sec
BUILD SUCCESSFUL
Total time: 34 seconds
6168
days inactive
6168
days old
jboss-development@lists.jboss.org
8 comments
5 participants
participants (5)
-
Adrian Brock -
Ales Justin -
Anil Saldhana -
David M. Lloyd -
Dimitris Andreadis