Hi,

I have finished updated the packages org.ten60.transport.http.* in order to porting to jetty 6. Now the http server starts and can handle request. However exceptions are captured when requests contains parameters, and the root cause is

Id:   java.lang.ClassCastException Message:   [Ljava.lang.String; cannot be cast to java.lang.String Callstack:    org.ten60.netkernel.xml.transrepresentation.NVPToXML.transrepresent() line:76 org.ten60.netkernel.layer1.nkf.impl.NKFTransreptorImpl.transrepresent() line:89 com.ten60.netkernel.scheduler.Scheduler.transrepresent() line:573 com.ten60.netkernel.scheduler.Scheduler.stateTransrepresent() line:532

E.g. request http://localhost:8080/workbench/example_dpml/helloParams.idoc?myparam=Hello
or search at
http://localhost:1060/ep+name@app_fulcrum_backend_index

I am not sure if someone can help look into this. I read the source of NVPToXML   and cannot find any clue.

I also want to contribute the updated tpt-http-2.2.1.jar with source, but do not know how to do that.

Cheers,

Dong

Id:   java.lang.ClassCastException Message:   [Ljava.lang.String; cannot be cast to java.lang.String

This looks like it is trying to cast a String[] to String. I've looked at the line of and it is casting the object from an iterator obtained from IAspectNVP.getValues(String aKey). So I'd guess that your new code is putting a String array rather than Strings into the NVP Aspect. Take a look at where you are constructing that Parameter NVP.

This sound like a great contribution. As far as contributing the updated HTTP transport that would be fantastic! If you are happy to assign joint copyright we can sent you a simple form to fill and we can incorporate and would be very appreciative. If you'd like to manage and host it yourself as an add -on module that would be fine too.

How are you finding the latest Jetty code. Does the NIO make a difference? Did you manage to make the NetKernel transport fully asynchronous so it doesn't block a thread for each request?

Cheers,
Tony

The problem related to NVP is fixed. I found the NVP bug is related to MultiMap of jetty. I am not sure why it is OK for jetty 5 but not for jetty 6. The used methods of MultiMap did not change from jetty 5 to jetty 6 according to their source code.

I would like to have joint copyright. It is good to collaborate. 

The jetty I tested is the latest version, jetty-6.1.6 - 18 November 2007. You can get it from http://dist.codehaus.org/jetty/ . The jar I created has the same structure as the old tpt-http-2.2.1.jar. The only dependency on jetty is jetty-6.1.6.jar and jetty-util-6.1.6.jar for about 628 KB. The dependency on jetty-util-6.1.6.jar can be removed though if wanted.

I am working on the evaluation of {NIO,BIO}X{Async,sync} setup of the platform. Do you have some suggestion on benchmark? And I am not if it is also do the testing for a single/multiple core aspect.

Cheers,

Dong

The problem related to NVP is fixed. I found the NVP bug is related to MultiMap of jetty. I am not sure why it is OK for jetty 5 but not for jetty 6. The used methods of MultiMap did not change from jetty 5 to jetty 6 according to their source code.

Take a look at the following class: org.ten60.transport.http.parameter.representation.ParameterNVPAspect

It provides the translation from the underlying jetty Multimap to the IAspectNVP implementation. API documentation for Jetty is often sparse but it looks like something has changed here. Maybe not the multimap itself but what Jetty puts into it. So the adaption code in the HTTP transport will need to change too.

I am working on the evaluation of {NIO,BIO}X{Async,sync} setup of the platform. Do you have some suggestion on benchmark? And I am not if it is also do the testing for a single/multiple core aspect.

I'd suggest a few of benchmark tests:

1) test serving a static image resource from NetKernel, one that will be cached inside NetKernel and will be served with minimal computation.

2) create a test service inside NetKernel which does little work but has an elapsed time. For example using a Thread.sleep() statement. Then fire lots of concurrent requests at NetKernel and see what happens. You may want to increase the number of scheduler threads in system.xml for this test.

3) create a compute intensive service and profile this to see if the changes show any real world benefits.

Metrics I'd look at would be throughput, response time and Java heap usage as I varied the load.

You might be interested in this paper we wrote a while ago now:
http://docs.1060.org/docs/3.3.0/book/administratorguide/doc_whitepaper_scalability.html

Cheers,
Tony

Hi Tony,

I think the three aspects cover most of the usage cases. I will try according to them.

The scalability page was already in my bookmarks. It is one of the reasons that I want to develop my project based on NetKernel. Do you still have the configuration file of JMeter and the corresponding NetKernel setup and resources? I can use them to test if NIO makes different on the scalability and performance of NetKernel.

I am working on securing the admin interface using jetty Realms. I found the method described in http://www.1060.org/forum/topic/265/2 does not work for me. I have tried using jetty 5 realms to do that, and it works, and is easy to configure. I will post the solution for jetty 5 latter here.

Another question is where I should upload the source and jar I created. Email to you?

Cheers,

Dong