[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation
by mstruk
anonymous wrote : I don't see why this asynch behavior is necessary.
Maybe I should explain a little :)
There is a tradeoff between performance and releasing of file locks when it comes to zip files. Every opening of a zip file comes with an overhead. So - to maximize performance, you open a zip file (acquire a lock) and never release it.
That's how current trunk works, and we don't like it for obvious reasons.
So I implemented the other extreme. For every file that was read from a zip archive a zip file was opened, file was read, and then a zip file was closed right away. This resolved the locking problem but came with a performance penalty - reopening a zip file for every entry.
To have the best of both worlds the obvious solution is to not close a zip file immediately after every use, so that the next time an already open file can be reused, but still close it after a few seconds so that locks are being released.
Now, you have no guarantee after any call to VFS that another call will occur within a reasonable time. If the last call left the zip file open the file may remain open for a long time.
There are only two alternatives that I see here - use a third thread, or mandate at the level of VFS API that clients need to do polling - either through existing method - like getLastModified() - or through special method.
The third-thread-option seems less nasty to me than relying on API client for proper operation. Although I suppose MC's VFS deployer does a regular polling and maybe could be relied upon in this matter? Also consider that release period will then be defined by MC's polling period in that it can only be a period of that, and can't be shorter than that.
My implementation on the other hand is completely autonomous. It uses a daemon timer thread, that autodetects lack of activity and cancels itself out - getting reinitialized when activity reoccurs. So a third thread only exists for a brief period of time - at start up and at redeployment, other times it's not even there.
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153696#4153696
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153696
17 years, 7 months
[Design of JBoss ESB] - Re: ESB vs. SOAP community
by Kevin.Conner＠jboss.com
Thomas, I think I need you to explain further what it is that you expect to get out of this 'integration project' and why it will be any different to the integration currently done within ESB.
The work to create the platform did discover a number of issues but those have been fed back into the appropriate projects (WS, ESB, jBPM, drools) or resulted in new projects being created (SSO, governance).
The remaining work in the platform is the additional QE, docs and pre-configuration of the 'production' instance. I don't believe any of this is different from the work that goes into the EAP.
The aspect that appears to be missing at present is the ability to take an ESB build and specify the versions of our dependencies, hence the platform team is also responsible for building and overwriting those versions within the generated ESB artifacts. This is being worked on and will be in place before the next platform GA release.
Given all this, what is still missing? What do you see this new project adding that is not currently being covered?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153661#4153661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153661
17 years, 7 months
[Design of JBoss ESB] - Re: ESB vs. SOAP community
by Kevin.Conner＠jboss.com
"thomas.diesler(a)jboss.com" wrote : How as a community member do I verify and contribute to SSO for SOA-P?
I assume that you are referring to the project that has just been started to create this, in which case contributing to the SSO project (or whatever Mike Brock/Anil call it) would be a good move.
"thomas.diesler(a)jboss.com" wrote : AFAIU, I cannot because it is part of some proprietary build. This is just a simple example, but it can reasonably be expected that the delta between JBossESB and the SOA-P will grow (not every SOA aspect is an ESB concern)
And it is a bad example as the only thing that the current SSO does is configure the normal security access inherent in the app server so that each console uses the same credentials. Pure jaas, nothing more, in the current SOA-P.
"thomas.diesler(a)jboss.com" wrote : As things stand now the ESB team would have to deal with all those aspects.
Sorry Thomas, you are reading far too much into this. The current SSO stuff will be replaced by the new project, that is why it was started in the first place. What other aspects are you thinking about?
"thomas.diesler(a)jboss.com" wrote : Also it concerns me that calls to test-drive the SOA-P are being ignored because folks don't care about some proprietary build that is not available to the community.
Which is, of course, not true. They can 'test-drive' it through the projects and their integration with AS. We certainly have a lot of people 'test-driving' the ESB integration.
"thomas.diesler(a)jboss.com" wrote : More positively, the call to test drive the next SOA-P release should of course reach the entire community.
Our community does help to test drive the ESB integration, I'm sure the WS one does the same on behalf of WS/EAP.
"thomas.diesler(a)jboss.com" wrote : Finally one should not forget that EAP is successful because a large community had access to JBossAS. The same obviously applies to SOA-P
Sorry, are you suggesting that SOA-P is failing?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153621#4153621
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153621
17 years, 7 months
[Design of JBoss ESB] - Re: ESB vs. SOAP community
by thomas.diesler＠jboss.com
How as a community member do I verify and contribute to SSO for SOA-P?
AFAIU, I cannot because it is part of some proprietary build. This is just a simple example, but it can reasonably be expected that the delta between JBossESB and the SOA-P will grow (not every SOA aspect is an ESB concern)
As things stand now the ESB team would have to deal with all those aspects.
Also it concerns me that calls to test-drive the SOA-P are being ignored because folks don't care about some proprietary build that is not available to the community.
More positively, the call to test drive the next SOA-P release should of course reach the entire community.
Finally one should not forget that EAP is successful because a large community had access to JBossAS. The same obviously applies to SOA-P
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153614#4153614
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153614
17 years, 7 months
[Design of JBoss Profiler] - Re: Crash when stopping JbossProfiler 2.0.Beta 1
by pisce
Hello,
I think I won't be able to provide such an app, since it occurs very randomly (or so it seems) in my very app...
Anyway, here's something I never noticed before... after one of those crashes, I killed (ctrl+c on Windows) my JBoss AS and got this server-side error:
14:56:23,946 ERROR [STDERR] Exception in thread "Thread-0" (Thread-0)
14:56:23,950 ERROR [STDERR] java.lang.NullPointerException (Thread-0)
14:56:23,958 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:630)
(Thread-0)
14:56:23,963 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) (Thread-0)
14:56:23,967 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:4
74) (Thread-0)
14:56:23,974 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
(Thread-0)
14:56:23,984 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) (Thread-0)
14:56:23,988 ERROR [STDERR] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) (Thread-0)
14:56:23,990 ERROR [STDERR] at java.lang.Class.forName0(Native Method) (Thread-0)
14:56:23,993 ERROR [STDERR] at java.lang.Class.forName(Class.java:242) (Thread-0)
14:56:23,998 ERROR [STDERR] at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactor
y.java:95) (Thread-0)
14:56:24,004 ERROR [STDERR] at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) (Threa
d-0)
14:56:24,010 ERROR [STDERR] at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) (Thre
ad-0)
14:56:24,016 ERROR [STDERR] at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) (Thread-0
)
14:56:24,022 ERROR [STDERR] at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:181) (T
hread-0)
14:56:24,028 ERROR [STDERR] at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) (
Thread-0)
14:56:24,034 ERROR [STDERR] at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) (T
hread-0)
14:56:24,041 ERROR [STDERR] at java.lang.Class.initAnnotationsIfNecessary(Class.java:3031) (Thread-0)
14:56:24,043 ERROR [STDERR] at java.lang.Class.getDeclaredAnnotations(Class.java:3019) (Thread-0)
14:56:24,046 ERROR [STDERR] at org.jboss.profiler.agent.ClassUtil.isSession(ClassUtil.java:152) (Thread-0)
14:56:24,050 ERROR [STDERR] at org.jboss.profiler.agent.ClassUtil.getClasses(ClassUtil.java:94) (Thread-0)
14:56:24,054 ERROR [STDERR] at org.jboss.profiler.agent.Profiler.stopProfiler(Profiler.java:146) (Thread-0)
14:56:24,056 ERROR [STDERR] at org.jboss.profiler.agent.Agent$1.run(Agent.java:918) (Thread-0)
Hope this helps!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153591#4153591
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153591
17 years, 7 months