[JBoss AS Development] - Re: Naming over Remoting 3
by ron.sigal＠jboss.com
Hey A,
Hope I'm not being too familiar, addressing you by your first initial. :)
I've been playing around with combining invokablecontainer and proxies, and I have a problem.
If I redefine Interceptor.invoke() to accept an org.jboss.invokable.container.api.Invocation instead of an org.jboss.invocation.Invocation, if I adjust ClientContainer to hold an org.jboss.invokable.container.api.InvocationContext instead of an org.jboss.invocation.InvocationContext, and if I redefine ClientContainer.invoke() to create an org.jboss.invokable.container.core.InvocationImpl instead of an org.jboss.invocation.Invocation, then I have a problem injecting the ClientContainer's InvocationContext into the Invocation. I wanted to use the constructor
| InvocationImpl(final Method targetMethod, final Object[] args, final InvocationContextProvider context)
|
but it's a package-whatever. And if I call Invocation.getContext() to populate it with ClientContainer's InvocationContext, I can't really do much because InvocationContext doesn't have an iterator, just
| Object getProperty(Object key) throws IllegalArgumentException;
|
which doesn't help if I don't know what's in the InvocationContext.
Am I just trying to do something that doesn't make sense? Otherwise, what do you think of adding an iterator to InvocationContext?
-Ron (you can call me R)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268906#4268906
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268906
16 years, 4 months
[JBoss Microcontainer Development] - Old UCL Repository containing URLClassLoader references
by flavia.rainone＠jboss.com
Yesterday, when I was finishing up the cleanup of the classpool tests (JBREFLECT-74), I found a test that was being run only on the sanity test case but not on the classpool test.
The new structure of the tests allows using the same test code to test both classpools and classloaders. Hence, the test scenario that was only being run on the sanity test case is now run on the classpool test case as well. And this uncovered a failure. :-(
This is the problematic scenario:
- URLClassLoader associated with b.jar (contains B.class) is the parent of Unified Class Loader A (below)
- UCL A associated with a.jar, is in the global repository
- UCL B, associated with b.jar, is in the global repository
When UCL A is requested to load B.class, it will load the class from the parent URLClassLoader.
The loaded class is put into the classes cache collection, and the pair UCL A, B.class is put in the loaderToClassesMap (both collections belong to the global repository).
During cleanup, UCL A is removed from the repository and, since B.class is mapped by UCL A in the loaderToClassesMap, the B.class is removed from the classes collection.
But on the ClassPoolTestCase, B.class is is associated to the parent URLClassLoader in the loaderToClassesMap collection. As a result, the B.class is not removed from classes collection during cleanup. That B.class in the classes cache is garbage and will cause failure to the next test. The cause of this difference in behavior is that UCL A is registered in the repository as a dynamic class loader*, and this causes an important if statement of LoadMgr3 to be skipped.
My question: is the loaderToClassesMap allowed to contain class loaders that are not in the repository, as in the scenario described?
_________________
* I understand that this will allow the repository to find new classes generated by the ClassPool. During the creation of a JBossUclDelegatingClassPool, a temp file URL is added to the UCL, and the UCL is added to the repository as a dynamic ClassLoader.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268890#4268890
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268890
16 years, 4 months
[Embedded JBoss Development] - Re: Embedded API Design Problems
by jason.greene＠jboss.com
I disagree with the server factory example in Rule 4. IllegalArgumentException is the appropriate exception to be thrown since, if you look at the code, it pertains to the parameters that are passed to the method. It is true that the exceptions is thrown by a different class, but this class is the implementation of the API. So as long as the behavior is consistent to the API then this is fine. There is definitely no need to transfrom IllegalArgumentException into a checked exception, as it is a pure runtime error that indicates misuse of the API. In other words, it is more of an assertion than it is a true exceptional condition.
I am indifferent on putting RuntimeExceptions in the throws clause. At the end of the day, it doesn't really matter, and usage of the javadoc @throws is just as effective IMO.
I do agree with the API consistency argument, however I disagree with using get/set with method chaining. If you are doing a DSL style method chain, you don't need get/set, its just extra verbosity. Get is logically the no-arg version, and Set is logically the version which takes arguments. In general I think Java developers took the JavaBean recomendations WAY to far. The whole reason JavaBeans required get & set notation was so that an automated tool could figure out what the "properties" are. In other words, JavaBeans are a big hack.
Also, as a more general comment, Bloch's advice is just that, advice. API design is somewhat subjective, so we shouldn't treat them as hard and fast rules.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268875#4268875
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268875
16 years, 4 months
[JBoss Profiler Development] - Re: Beta6 remaining issues
by jesper.pedersen
anonymous wrote :
| Is it allowed to store them somewhere on the filesystem? You do not want to keep them in memory and serve them from there do you?
|
What ever is easiest to start with - first goal is just to have something running.
anonymous wrote :
| One of the things that needs documenting though is how to work with getSnapshot, snapshot, save, load etc.. it is kind of confusing ;-) this all in combination with storing data (not the html) in file, not in memory. I do not seem to be able to get that to work AND get a snapshot from it.
|
Yeah, the documentation could be more clear - "getSnapshot" downloads an existing snapshot from the agent and generate the reports, "snapshot" stops the profiler and downloads that snapshot, "save" downloads a snapshot from the agent and "load" generates the reports for a snapshot.
anonymous wrote : What is the best forum to ask about a 'transactional file store
The JCA user forum
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268872#4268872
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268872
16 years, 4 months
[JBoss Remoting Development] - Performance (CPU Utilization costs, for remote calls across
by bainwohl
I ran a simple experiment to try and measure the performance impact of using a remote session versus a local session within a jboss cluster. More specifically, I was looking at CPU utilization. It involved the following components:
IEchoServer, IEchoServerLocal, IEchoServerRemote interfaces
- the IEchoServer interface has one method
- MyMessage echo(MyMessage)
- IEchoServerLocal and IEchoServerRemote both extend the IEchoServer Interface, with a @Local and @Remote annotation, respectively
EchoServer
- implementation of the IEchoServerLocal and IEchoServerRemote interfaces with a @Stateless annotation
- one line implementation of the "MyMessage echo(MyMessage msg) interface, return msg;
Message Producer MBean:
- this MBean is capable of producing messages at a specified rate
- the messages created, MyMessage, is a POJO with a number of properties with getters and setters
- the message also contains a byte[] payload
- the message producer can be configured to generate messages with a text payload or a random binary payload, of a specified length
- a custom handler is used to consume the generated messages
- for the purposes of the test, the custom handler calls out to the
IEchoServer interface
- it can be configured to call out to the local session or the remote session running on a different box (passed the hajndi binding name).
We have two test machines, each running JBoss (5.0.1.GA), H1 and H2 respectively. The machines are both quads. All CPU utilization numbers are out of 400%.
Deployed on each machine is the following:
- MessageProducer MBean
- EchoServer SLSB (both local and remote)
On both H1 and H2:
- the IEchoServerLocal implementation is bound as EchoServer/local
On H1:
- the IEchoServerRemote implementation is bound as EchoServer_H1
On H2:
- the IEchoServerRemote implementation is bound as EchoServer_H2
Very simple stuff; for each of the following test cases I had the message producer push messages at a specified rate. Each message has a text payload of 1000 bytes.
In the remote test, messages produced on H1 call out to "EchoServer_H2" and messages produced on H2 call out to "EchoServer_H1".
Test Case One:
H1: MessageProducer, generating MyMessage instances @ 400msg/sec, with a 1000byte payload, calling out to the local EchoServer SLSB
H2: does nothing
Results: H1_CPU_Utilization=2.5%,H2_CPU_Utilization=0
Test Case Two:
H1: MessageProducer, generating MyMessage instances @ 400msg/sec, with a 1000byte payload, calling out to the remote EchoServer SLSB running on H2
H2: accepts calls to the EchoServer SLSB, from H1
Results: H1_CPU_Utilization=34%, H2_CPU_Utilization=32%
THIS IS NOT A MISTAKE!
Test Case Three:
H1: MessageProducer, generating MyMessage instances @ 200msg/sec, with a 1000byte payload, calling out to the remote EchoServer SLSB running on H2 AND accepts call to the EchoServer SLSB from H2
H2: MessageProducer, generating MyMessage instances @ 200msg/sec, with a 1000byte payload, calling out to the remote EchoServer SLSB running on H1 AND accepts call to the EchoServer SLSB from H1
Results: H1_CPU_Utilization=35%, H2_CPU_Utilization=35%
Test Case Four:
H1: MessageProducer, generating MyMessage instances @ 400msg/sec, with a 1000byte payload, calling out to the remote EchoServer SLSB running on H2 AND accepts call to the EchoServer SLSB from H2
H2: MessageProducer, generating MyMessage instances @ 400msg/sec, with a 1000byte payload, calling out to the remote EchoServer SLSB running on H1 AND accepts call to the EchoServer SLSB from H1
Results: H1_CPU_Utilization=66%, H2_CPU_Utilization=70%
Of course, the round trip latency increased by an order of magnitude, when comparing local to remote calls, however, this was expected.
I can see via netstat that TCP/IP connections are coming and going during tests 2,3 and 4.
I'm wondering where all the CPU is going. Is it used opening and closing socket connections or is it the cost of serialization and writing/reading to and from the socket?
Presumably, I'm already using JBoss Remoting over sockets.
The question is, is this as good as it gets? Can I tweak the configuration to improve this? Any help would be greatly appreciated.
Cheers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268868#4268868
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268868
16 years, 4 months