[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by reverbel
"mark.little(a)jboss.com" wrote : However, although I understand why you're doing this reference approach, I'm not convinced it buys you much. The size of an IOR is so large anyway when compared to an Xid, that saving a few bytes is unlikely to make much of a difference on the number of blocks that get written in the log. It's the number of physical disk blocks and not the amount of information, that makes a difference.
The difference needs to be measured. An Xid can take up to 128 bytes, but in an IOR it will take up to 256 bytes, due to the encoding of bytes as pairs of ASCII characters that represent hex digits. This looks like a significant increase in the size of IORs, but it may or may not have a significant impact on the performance of marshalling, transaction context propagation, and logging tasks. The impact is more likely to be significant in the case of JBossRemoting, whose URIs are much smaller than IORs and WS-Addressing endpoint references. But it needs to be measured anyway.
It appears that we are in agreement that this is a reasonable approach, which has a conceptual advantage (it avoids nesting of globally unique identifiers), but whose practical benefits need to be validated by measurements.
Regards,
Francisco
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978296#3978296
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978296
19 years, 6 months
[Design of JBossCache] - API Issues integrating 2.0.0.DR1 in HEAD
by bstansberry＠jboss.com
I'm starting to integrate 2.0.0.DR1 and here's what I've hit so far:
1) How do you set an Option? I thought there was an InvocationContext.currentContext() or something. Doesn't seem to be. Only thing I see is a getter/setter in CacheSPI, but my code shouldn't need CacheSPI.
2) It's not possible to learn anything about the cache loader configuration via the Cache interface, unless you're willing to parse an Element. We need to find a way to expose stuff. Specifically what's needed for session repl are:
a) is there a cache loader?
b) is it set for passivation?
c) is it shared?
Less critical:
3) Let's expose the TransactionManager as a Configuration property. In the session repl case, the cache is using special transaction manager. The session repl code needs to get it so it can control the tx. For other use cases, if the environment (like JBoss AS) supports it why not dependency inject the TM into the cache rather using a TransactionManagerLookup? TransactionManagerLookup becomes a fallback for cases where we can't dependency inject.
4) Can we restore Node.getChildrenNames()? Iterating through the child collection and calling getFqn().getName() on each node is a pain.
5) Why is Node.getChildren() a Collection and not a Set? I expect it's because Map.getValues() is a Collection, but properly this method should return Set.
6) The Node interface desribes various returned Collections as being immutable. From a glance at NodeImpl it looks like they aren't. Also, it would be good to be more clear about thread safety as immutable and thread safe aren't the same.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978294#3978294
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978294
19 years, 6 months
[Design the new POJO MicroContainer] - Parameter matching issue?
by scott.stark＠jboss.org
It seems like I have seen this a few times now. I updated the SuffixMatchFilter to include two new ctors SuffixMatchFilter(List) and SuffixMatchFilter(List, VisitorAttributes) in addition to the previous SuffixMatchFilter(String) and SuffixMatchFilter(String, VisitorAttributes). This should be a compatible change, but the existing WARStructure deployment:
| <!-- WAR Structure -->
| <bean name="WARStructure" class="org.jboss.deployers.plugins.structure.vfs.war.WARStructure">
| <property name="webInfLibFilter">
| <!-- We accept all .jar files in WEB-INF/lib -->
| <bean name="WebIInfLibFilter" class="org.jboss.virtual.plugins.vfs.helpers.SuffixMatchFilter">
| <constructor><parameter>.jar</parameter></constructor>
| </bean>
| </property>
| </bean>
|
started failing:
| 13:44:34,650 ERROR [AbstractKernelController] Error installing to Instantiated: name=WebIInfLibFilter state=Described
| java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.util.List] actual=[java.lang.String]
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:224)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:140)
| at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:104)
| at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:71)
| at org.jboss.kernel.plugins.dependency.InstantiateAction.installAction(InstantiateAction.java:52)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:96)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:300)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:270)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:117)
| at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
|
I'm guessing the type of the ctor arg is not being used?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978287#3978287
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978287
19 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests
by rachmatowicz＠jboss.com
I'm having a problem with a Remoting exception when running a generic test case against the scoped meessaging deployment:
16:14:04,084 INFO [ServerPeer] JBoss Messaging 1.0.1.GA server [server.0] started
16:14:04,126 INFO [Queue] Queue[/queue/D] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,155 INFO [Queue] Queue[/queue/ex] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,169 INFO [Topic] Topic[/topic/testDurableTopic] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,174 INFO [Queue] Queue[/queue/testQueue] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,178 INFO [Topic] Topic[/topic/openTopic] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,182 INFO [Queue] Queue[/queue/C] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,186 INFO [Topic] Topic[/topic/securedTopic] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,191 INFO [Queue] Queue[/queue/DLQ] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,195 INFO [Queue] Queue[/queue/B] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,627 INFO [ConnectionFactory] Connector socket://10.16.6.135:4457 has leasing enabled, lease period 20000 milliseco\nds
16:14:04,627 INFO [ConnectionFactory] [/ConnectionFactory, /XAConnectionFactory, java:/ConnectionFactory, java:/XAConnectio\nFactory] deployed
16:14:04,631 INFO [Topic] Topic[/topic/testTopic] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,637 INFO [Queue] Queue[/queue/A] started, fullSize=75000, pageSize=2000, downCacheSize=2000
16:14:04,653 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,nam\e=JmsXA' to JNDI name 'java:JmsXA'
16:14:04,673 INFO [WebMetaData] WebMetaData:importJBossWebXml: maxActiveSessions = -1
16:14:04,691 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
16:14:05,106 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-10.16.6.135-8080
16:14:05,147 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-10.16.6.135-8009
16:14:05,169 INFO [Server] JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200610131450)] Started in 35s:956ms
16:14:07,479 ERROR [ServerThread] failed to process invocation.
java.io.IOException: Can not read data for version 6. Supported versions: 1,2
at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:394)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:446)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
16:14:08,373 INFO [Server] Shutting down the server, blockingShutdown: false
I have seen this problem reported on the Messaging forums:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89684
In my case, I am starting up AS with a scoped 1.0.1.GA messaging configuration and trying to execute the test case ConcurrentDeliveryTestCase. This test case happens to create temporary queues, but not with any provision for scoping, as far as I am aware. Would this be a possible cause of the problem?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978284#3978284
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978284
19 years, 6 months
[Design of JBossXB] - Re: Using annotations to define schema mappings
by jason.greene＠jboss.com
I checked and JAXB does the same thing to support the binding file. xjc loads it into a DOM tree, then applies the bindings using xpath, then parses the modified DOM.
To answer your question though, I think XSModel is flawed in a number of ways, and IMO we need to move away from it.
These include
| [1] not very extensible
| [2] incomplete / buggy
| [3] tied to xerces
| [4] language neutral API that is a bitch to work with in java
| [5] can't use it to write schema
|
|
| The sun jaxb implementation has a seperate model for reading a writing. They externalized their reading implementation, its called XSOM:
|
| https://xsom.dev.java.net/
|
| See the design overview here:
| https://xsom.dev.java.net/implementation.html
|
| For writing they basically implement a light weight model that only writes what they generate.
|
| I think we should look into switching to XSOM because it doesn't suffer from problems 1-4. It is quite efficient, uses SAX, and it supports customization using visitors.
|
| Although, I don't think this solves the overall problem in the java world, which is the lack of a standard XML Schema api that supports both reading and writing. The only thing close to it I have seen is the eclipse schema model, but it is tied to tons of bloated dependencies.
|
| -Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978265#3978265
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978265
19 years, 6 months
[Design of POJO Server] - Re: Need more metadata for the JARStructure deployer
by scott.stark＠jboss.org
The current StructureMetaData used by the DeclaredDeployer consists of:
| public class StructureMetaData
| {
| private HashMap<String, ContextInfo> contexts = new HashMap<String, ContextInfo>();
|
| public void addContext(ContextInfo context)
| {
| contexts.put(context.getVfsPath(), context);
| }
| public ContextInfo getContext(String vfsPath)
| {
| return contexts.get(vfsPath);
| }
| }
|
| public class ContextInfo
| {
| static class Path
| {
| private String name;
| private String[] suffixes = {};
| Path(String name, String suffixes)
| {
| this.name = name;
| if( suffixes != null )
| this.suffixes = suffixes.split(",");
| }
| public String getName()
| {
| return name;
| }
| public String[] getSuffixes()
| {
| return suffixes;
| }
| }
|
| /** The relative VFS path */
| private String vfsPath;
| /** The optional context classpath */
| private ArrayList<Path> classPath;
| /** The optional context metadata path */
| private String metaDataPath;
|
| public List<Path> getClassPath()
| {
| return classPath;
| }
| public void setClassPath(List<Path> classPath)
| {
| if( this.classPath == null )
| this.classPath = new ArrayList<Path>();
| this.classPath.clear();
| this.classPath.addAll(classPath);
| }
| public String getMetaDataPath()
| {
| return metaDataPath;
| }
| public void setMetaDataPath(String metaDataPath)
| {
| this.metaDataPath = metaDataPath;
| }
| public String getVfsPath()
| {
| return vfsPath;
| }
| public void setVfsPath(String path)
| {
| this.vfsPath = path;
| }
| }
|
So you have a map of deployment contexts (ContextInfo) with the key being the VFS relative path for the deployment context.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978264#3978264
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978264
19 years, 6 months