jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: New Contributors

[<ovi...@jb...>]

I would like to welcome Rajdeep Dua to our project. After a quite active presence on the forum, he submitted his first patches http://jira.jboss.org/jira/browse/JBMESSAGING-53 and the results of his first attempt to create a distributed test framework, which we hope to use with Messaging and possibly other projects.  Rajdeep is interested in unit testing, compliance testing and performance benchmarking.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876389#3876389

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876389

[Jboss-dev-forums] [Design of JBoss Build System] - Re: project structure and build descriptors

[<sco...@jb...>]

So its not an issue to have the imported project using whatever xsd they want, at least for a simple example:


  | build.xml:
  | <project name="Top" default="echo">
  |    <import file="subproject.xml" />
  |    <target name="echo">
  |       <echo message="top echo" />
  |       <antcall target="subproject-echo" />
  |    </target>
  | </project>
  | 
  | subproject.xml
  | <project
  |    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |     xsi:noNamespaceSchemaLocation="subproject.xsd">
  |    <target name="subproject-echo">
  |       <echo message="echo from subproject" />
  |    </target>
  | </project>
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876388#3876388

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876388

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[<ovi...@jb...>]

anonymous wrote : I still don't think returning an Object from the handleCallback() method is a good idea since, from the server side, will never be sure of the real behavior (if client is pulling the callbacks, the return from the handleCallback() method will always be null, even if this is not the value the client intended to return). This is just the nature of allowing pull model for callbacks.

You are right, I totally disregarded pull callbacks, since I don't use them, so far. 

anonymous wrote : I would be happy to (and will) add a getUserException() to the HandleCallbackException, which will be null in the case of pull callbacks. All of this I have commented in JBREM-93.

That will do. Will you also avoid generating error messages in case of an user HandleCallbackException and let the client code worry about it?


anonymous wrote : What I think you really need is the ability to make return invocations on the client (or to be more specific, the client's server) directly, without having to use the callback API (because of the whole push/pull issue). My initial thought on this is to actually supply a Client object in the InvocationRequest given to the ServerInvocationHandler implementation (via the invoke() method). This way you can keep a reference to this client as you wish and call directly on it. This can be a synchronous or asynchronous (oneway) call... however you want to do it. If is synchronous, there will be a return value supplied as well as throw an exception if needed. 

The whole point of using callbacks was to avoid the need of opening a second connection from server to client. This won't be possible if the client sits behind a firewall. I know that this is exactly what remoting does behind the scenes right now, but I hope we will have a UIL2-like transport in the future that will make this issue irrelevant.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876385#3876385

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876385

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[<tom...@jb...>]

The use case helps me understand what you are after.  Thanks.

I still don't think returning an Object from the handleCallback() method is a good idea since, from the server side, will never be sure of the real behavior (if client is pulling the callbacks, the return from the handleCallback() method will always be null, even if this is not the value the client intended to return).  This is just the nature of allowing pull model for callbacks.  

I would be happy to (and will) add a getUserException() to the HandleCallbackException, which will be null in the case of pull callbacks.  All of this I have commented in JBREM-93.

What I think you really need is the ability to make return invocations on the client (or to be more specific, the client's server) directly, without having to use the callback API (because of the whole push/pull issue).  My initial thought on this is to actually supply a Client object in the InvocationRequest given to the ServerInvocationHandler implementation (via the invoke() method).  This way you can keep a reference to this client as you wish and call directly on it.  This can be a synchronous or asynchronous (oneway) call... however you want to do it.  If is synchronous, there will be a return value supplied as well as throw an exception if needed.  

I am just thinking aloud here, so let me know if you think this would be a better fit for you?  Adrian, feel free to add your 2 cents on this idea as well.




View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876376#3876376

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876376

[Jboss-dev-forums] [Design of JBoss Build System] - project structure and build descriptors

[<sco...@jb...>]

I have been through the current build-reference.html doc and I'm finding an overall description of the build structure of a project in terms of what the directory structure needs to be, what types of build descriptors there are, what are there content models etc. to be missing. So I want a more top down doc that describes this. Some current issues:

- Why is all of the tools module being used? This is largely legacy stuff and includes extraneous stuff like cruisecontrol configuration. The jbossbuild tools could just be an element in repository.jboss.comwith a minimal jbossbuild/bootstrap cvs module to kickstart a project?

- The use of the ant project document structure for the different types of build descriptors (build.xml, component-info.xml, etc.) gets us into a problem with non-validatable documents. I'm sure this is due to leveraging the ant import mechanism, but ant does have a notion of namespaces, but I'm not sure if this applies to the project element on imported references. Have we looked into that? Ideally each different build descriptor type would have its own xsd. If we can't actually do this, we at least need xsds for the various build descriptors as a reference to what the allowed content models are.

I want to help get this stuff documented as a first time user of the build system to ensure we get it adopted as soon as possible.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876374#3876374

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876374

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<sco...@jb...>]

So we need to finalize the repository structure and component-info so I can recreate the jboss-4.0.x thirdparty contents from a jbossbuild.xml.

One current issue is the license info. The existing jboss-4.0/thirdparty/licenses/thirdparty-licenses.xml now has an index of the licenses used along with the acceptable source code headers used in the codebase to reference the license. The latter is used by the org.jboss.tools.license.ValidateLicenseHeaders utility to run across every source file in the codebase to validate that a license header exists, and that it maps to an acceptable license.

So the first change that needs to be made to the repository structure is to pull out all license files from the component dirs into a repository/licenses structure so that there is a canonical representation of the licenses in use. When I look at a licenseType="apache-2.0" reference from a component-info.xml, its a reference to either repository/licenes/apache-2.0 contents, or a reference to an element in a single repository/licenes/license-info.xml element not unlike the current thirdparty-licenses.xml licenses section:


  | <licenses>
  |       <license id="apache-1.1" licenseFile="apache-1.1.txt">
  |          <terms-header id="apache#0">
  |           * The Apache Software License, Version 1.1
  | ...
  | 

I would lean towards a single repository/licenes/license-info.xml with the license text in repository/licenes as currently is done in jboss-4.0/thirdparty/licenses.

I have some general questions about the overall build structure relationships and xml descriptors format that I'll create a seperate post on.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876369#3876369

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876369

[Jboss-dev-forums] [Design of JBossXB] - Re: General schema parsing

[<sco...@jb...>]

I have added another example to the existing head testsuite/xml tests that illustrates a complete deployment document that involves 3 namespaces/schemas for a prototype dynamic login configuration service. The deployment document is the src/resources/testObjFactory.xml which is a simple jboss-4.0.x style mbean service descriptor. The namespace/xsd/object mappings are:

ns#1: urn:jboss:mbean-service
xsd#1: mbean-service_1_0.xsd
objects#1: org.jboss.test.xml.mbeanserver.{Services,MBeanData}

ns#2: urn:jboss:login-config2
xsd#2: login-config2.xsd
objects#2: org.jboss.test.xml.mbeanserver.{PolicyConfig,AuthenticationInfo,AppConfigurationEntryHolder,ModuleOption}

ns#3: urn:jboss:user-roles
xsd#3: user-roles.xsd
objects#3: org.jboss.test.xml.mbeanserver.{Users,Users.User}

A number of these objects do not have java bean setters. The constructor is the only way to pass in the read-only data in this case. Many use collection classes.

I would like to iterate on the schemas/object model to a point where the object graph can be completely driven by the schema binding. I also want to create a pojo server version which excercies the dependcies.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876364#3876364

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876364

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[<ovi...@jb...>]

The central issue seem to revolve around the statement: The server threads should not be blocked on communication or slow/unreliable clients

With the current design, the server-side Consumer endpoint synchronously calls into its corresponding client-side remoting callback handler, every time a new message is pushed to it by the core. 

If we want asynchronous delivery on the client (i.e. the message gets as soon as possible on the client, without polling), I don't think there is a way around that: the server thread will block calling callbackHandler.handleCallback(...) until something happens. That something could be:
1. a negative acknowledgement - the client says that nobody wants that message
2. a positive acknowledgment - the client says that it's got the message and now the client endpoint can acknowlege the message to the core.
3. an unchecked exception generated by a broken client 
4. a communication error of some sort, that bubbles out of remoting

The case 1 is detected immediately: there is no tread blocked in waiting on receive() or there is no message listener. The negative acknoweldgement can be generated pretty quickly in this case, and with no client code involvement.

For the case 2, the situation is a little bit more complicated. 

2.1 If there is client thread blocked in MessageConsumer.receive(), the callback handler will just hand over the message (my solution for this is to use a RendezVous object) and this is the positive acknowledgment. The client-side remoting thread will just unwind and the server will immediately get the positive acknowledgment.

2.2 However, if there is a message listener, the current implementation uses the remoting thread to invoke onMessage(). This can be a problem, since I have no control over how long onMessage() will take.  I can think at several solutions, to have a separate thead that invokes onMessage(), for example. 



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876361#3876361

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876361

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[<ovi...@jb...>]

Adrian's reply:

anonymous wrote : 
  | I think you are wrong Ovidiu.
  | I recently fixed this in JBossMQ to avoid the blocking:
  | http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60912
  | 
  | The client should refuse the delivery with an asynchronous NACK.
  | You should not block server threads on communication or slow/unreliable clients.
  | 
  | OFF-TOPIC:
  | I believe this also fixes an issue with distributed deadlocks that were a scourge
  | of the basic JBossMQ IL design that required the introduction of a thread pool
  | to handoff requests in UIL2.
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876359#3876359

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876359

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Synchronous vs. asynchronous NACK when client refuses delive

[<ovi...@jb...>]

I am starting a new design thread here, to separate it from the Remoting issue that sparkled it (http://jira.jboss.com/jira/browse/JBREM-93): 

anonymous wrote : 
  | Use case:
  | 
  | I am using a push callback to synchronously deliver a message to a JMS Client (MessageConsumer). My server-side consumer endpoint receives the message from the messaging core and synchronously invokes callbackHandler.handleCallback(...). The server-side thread is blocked until the push either succeeds or fails.
  | 
  | This invocation eventually reaches my callback handler on the client-side. However, the callback handler should be able to refuse the message: for example, nobody is blocked in a receive() and there is no message listener. There should be a way to politely say: yes, I have seen your message, but I don't need it and I don't want it, and here's my NACK.
  | 
  | With the current InvokerCallbackHandler.handleCallback() signature (public void handleCallback(InvocationRequest invocation) throws HandleCallbackException), the only way for the callback handler to send a NACK is to throw a HandleCallbackException
  | 
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876358#3876358

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876358

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: MatrixVersion design question

[<sco...@jb...>]

I'm not seeing how 4.0.2/4.0.1 are treated specially, and they should not be so can you explain how these are run by the matrix tests?

I don't see much benefit to including a list of expected versions in the build.xml as its non-functional unless the directory and these versions exist. This is really a test to be run by qa and published to the testsuite results site. Occasionally developers will run one legacy client against the pending current release to fix issues.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876357#3876357

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876357

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: Package names for JRunit

[<cle...@jb...>]

I forgot to mention org.jboss.jrunit.controller for the "Benchmark Controller".

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876350#3876350

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876350

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Package names for JRunit

[<cle...@jb...>]

I want to divide jrunit into some packages according to our features.

I'm kind of out of creativity, and I want to make sure these package names make sense.

We would have:

org.jboss.jrunit:
 - server - for the server driven framework
 - decorators - for all the decorators
 - communication - for all the classes used for Jgroups purposes - MessageBus will be here
 - communication.data - serializable classes using for communication 
 - exception - kind of obvious - all the exception classes (no changes here)
 - utility or extensions (don't know yet)- For JunitExtensions - I needed that before - classes like SerializableTest would be in this package


Any thoughts? 


Clebert

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876349#3876349

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876349

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: MatrixVersion design question

[<cle...@jb...>]

By the other side, when developers are using the matrix testsuite they may want to test against a specific version. 

Adding this to the build.xml would require everybody to run only targets we have mapped in the build.xml.

IMO, the way we have now, anyone who wants to execute the matrix test can manage his own environment while we can put any version we want at cruisecontrol. 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876348#3876348

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876348

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: MatrixVersion design question

[<rya...@jb...>]

I don't think this is a huge issue.

The only problem I see is that the versions we are testing are not explicitly documented in the source code.  They are implicit based on what directories your ant task finds.

Generally, it is better to have explicit expectations of the environment, rather than letting your environment to drive your tests. IE, these are the versions we want to test and we will fail if we don't find them. 

I suggest that the desired compatability matrix should be documented in testsuite/build.xml.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876346#3876346

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876346

[Jboss-dev-forums] [Javassist development Forum] - how i can use metaobject for intercept method invocation?

[icecrash <nu...@jb...>]

i have a test class named prova;
i want run class prova and intercept methos invocation,field reading,writing,and object instantiation.
I write this the follow code:


  | try{
  |      javassit.reflect.Loader cl = new javassit.reflect.Loader();
  |      cl.makeReflective("prova","VerboseMO","javassist.reflect.ClassMetaobject");
  | cl.run("prova",args);
  |     }
  | cath(Throeable e){}
  | 

and the class VerboseMO:


  | class VerboseMO extends Metaobject
  | {
  |  public VerboseMO(Object base,Object args[])
  |  {
  |   super(base,args);
  |  System.out.println("Reflective Output: New instance of:"+base.getClass().getName()+"created");
  |  }
  | 
  |  public Object trapFieldRead(String name)
  |  {
  |   
  |  }
  | 
  |  public Object trapMethodcall(int id, Object[] args)
  |  {
  |   
  |  }
  | 
  | }
  | 
  | 

this code work ,but do not know how i can intercept method call and feild call:read or write.

Can anyone help me?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876345#3876345

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876345

[Jboss-dev-forums] [Design of JBoss Portal] - Documentation for RC

[<roy...@jb...>]

I'm touching up the docs now and adding in some of the new features. Let me know if I've left anything out:

Required:
Theme API
UserPortlet (new features)
RolePortlet (new features)
Installation steps (mostly the new installer here)
Custom Portlet Example (descriptor change)
Assigning Portlets to a Page (I get asked this from time to time)

Optional:
Struts Portlet integration

Anything else anyone can suggest that they'd like to see?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876336#3876336

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876336

[Jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re: Tomcat performance change to reduce concurrency...

[<sco...@jb...>]

Discussion of changes to the core of tomcat should be happening on the tomcat dev list, not here. It would only be revelvant here if they told you to get lost and wanted to pursue a jboss specific integration.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876332#3876332

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876332

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - MatrixVersion design question

[<cle...@jb...>]

The way I'm doing cross version tests is based in a directory.

By defining a directory, for example /jboss-versions, I'm going to look for sub-directories and dynamically execute the version check against each client defined on that directory.

For example, while testing 4_0_2, if you have 3_0_0 and 4_0_0 at /jboss-versions we will be doing cross refs tests against 3_0_0 and 4_0_0.  This is very dynamic, and when we move to 4_0_3 the only thing we will have to do will be to add another client library on this directory.

The only issue is that we won't any reference to 4.0.2 and 4.0.1 in the testsuite/build.xml as this test is done dynamically.  So, the question is: Is this an issue?


Clebert

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876329#3876329

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876329

[Jboss-dev-forums] [Design of POJO Server] - Re: PROTOTYPE - Transaction DataSource in a POJO environment

[<bil...@jb...>]

"ad...@jb..." wrote : "bil...@jb..." wrote : Hibernate is not a problem since EJB3 handles interaction with Hibernate.  What I need is JCA/TM/JNDI.
  | 
  | Which is what the prototype does. So the next stage is to make it into a real
  | standalone downloadable and identify kludges/improvements/haircuts with a roadmap
  | on JIRA.
  | 
  | I can do this, but I'd rather get on with my current roadmap/objectives
  | 1) Finalize the XML
  | 2) Ensure we have the integration with AOP working
  | 3) Fixing some of the TODOs (like the lifecycle annotation) with tests
  | 
  | These are basic foundations, it is not a wise idea to build things on sand ;-)

Cool, ok, i'll work on this...start from where you've begun

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876317#3876317

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876317

[Jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Tomcat performance change to reduce concurrency...

[Scott.Marlow.Novell <nu...@jb...>]

Hi,

I wonder if anyone has any feedback on a performance change that I am working on making.

One benefit of reducing concurrency in a server application is that a small number of requests can complete more quickly than if they had to compete against a large number of running threads for object locks (Java or externally in a database).  

I modified the Tomcat Thread.run code to use Doug Lea's semaphore support but didn't expose a configuration option (haven't learned how to do that yet).  My basic change is to allow users to specify the max number of concurrent servlet requests that can run.  If an application has a high level of concurrency, end users may get more consistent response time with this change.  If an application has a low level of concurrency, my change doesn't help as their application only has a few threads running concurrently anyway.

This also reduces resource use on other tiers.  For example, if you are supporting 500 users with a Tomcat instance, you don't need a database connection pool size of 500, instead set the throttle size to 20 and create a database connection pool size of 20. 

Current status of the change:

1.   org.apache.tomcat.util.threads.ThreadPool.CONCURRENT_THREADS is hardcoded to a value of 18, should be a configurable option.
2.  I hacked the build scripts to include Doug Lea's concurrent.jar but probably didn't make these changes correctly.

-Scott

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876314#3876314

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876314

[Jboss-dev-forums] [Design of JBoss Profiler] - Re: Memory Leak Interpretations

[<cle...@jb...>]

There is a new version I'm working, based on JVMTI that dumps the HEAP into text files. You can analyze these files later using a tool doing navigations.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876309#3876309

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876309

[Jboss-dev-forums] [Design of JBoss Profiler] - Re: Exception in front-end module

[<cle...@jb...>]

Are you sure you have stopped through the MBean before analyzing the results?

Also, you should stop your Jboss instance being profilled before analysing produced data. This is because all the .log.gz need to be closed

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876308#3876308

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876308

[Jboss-dev-forums] [Design of JBoss Profiler] - Exception in front-end module

[fredatwork <nu...@jb...>]

Hello,

I'm trying to use the profiler.

I run JBoss with the folowing option :
-XrunjbossInspector:G:/rubis_server_profiling,include=com.rubis.

I can stop/start/pause the profiler with throgh the JMX console and the profiler's MBean.

However when I attempt to see some results with the web application, I get the following web page after having clicked on the submit button:
<html><head><link rel="stylesheet" type="text/css" href="./imgs/cssdef.css"><title>Processing PID 1952</title></head>
  | <body>
  | <br>Opening g:\rubis_server_profiling\serverspy_1952_thread_1115138104234_140625000_0.log.gz
  | <br>Opening g:\rubis_server_profiling\serverspy_1952_thread_1115138104359_0_1.log.gz
  | java.io.EOFException
  | 	at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:201)
  | 	at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:191)
  | 	at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:131)
  | 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:58)
  | 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:68)
  | 	at org.jboss.profiler.web.servlets.ServletProcess.openStream(ServletProcess.java:39)
  | 	at org.jboss.profiler.web.servlets.ServletProcess.doGet(ServletProcess.java:114)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  | 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  | 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
  | 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
  | 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
  | 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
  | 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
  | 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
  | 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
  | 	at java.lang.Thread.run(Thread.java:595)
  | </init></init></body></html>
  | 

Any idea why this is ?

Fred

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876307#3876307

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876307

[Jboss-dev-forums] [Design of JBoss Profiler] - Exception in front-end war module

[${bb.Guest} <nu...@jb...>]

Hello,

I'm trying to use the profiler.

I run JBoss with the folowing option :
-XrunjbossInspector:G:/rubis_server_profiling,include=com.rubis.

I can stop/start/pause the profiler with throgh the JMX console and the profiler's MBean.

However when I attempt to see some results with the web application, I get the following web page after having clicked on the submit button:
<html><head><link rel="stylesheet" type="text/css" href="./imgs/cssdef.css"><title>Processing PID 1952</title></head>
  | <body>
  | <br>Opening g:\rubis_server_profiling\serverspy_1952_thread_1115138104234_140625000_0.log.gz
  | <br>Opening g:\rubis_server_profiling\serverspy_1952_thread_1115138104359_0_1.log.gz
  | java.io.EOFException
  | 	at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:201)
  | 	at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:191)
  | 	at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:131)
  | 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:58)
  | 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:68)
  | 	at org.jboss.profiler.web.servlets.ServletProcess.openStream(ServletProcess.java:39)
  | 	at org.jboss.profiler.web.servlets.ServletProcess.doGet(ServletProcess.java:114)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  | 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
  | 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  | 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
  | 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
  | 	at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  | 	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  | 	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
  | 	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
  | 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
  | 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
  | 	at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
  | 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
  | 	at java.lang.Thread.run(Thread.java:595)
  | </init></init></body></html>
  | 

Any idea why this is ?

Fred

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876306#3876306

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876306