Vert.x vs node.js

I kind of gave up on posting benchmarks on the web but I just found a post on the Vert.x blog with a benchmark that blew node.js out of the water so I just  did a quick run of those benchmarks and bottom line is I got ~ 60K/s using 4 vert.x instances and ~ 8K/s using 4 node.js processes.

I also ran vert.x directly using java (got the command line by looking at ps aux | grep java) in order to pass some JVM flags. Since I'm using a 64 bit OS I believe -server is on by default so I just experimented with -Xmx128m to reduce memory usage.

Here is my run of the benchmark:

Processor: Intel i7 Q820 - 4 cores + HT

OS: Ubuntu 11.04 x64

Java  1.7.0_01-b08

node v0.6.17

vert.x 1.0.final

 

Benchmark: ab -k -n 100000 -c 100 http://localhost:8080/

Mem analysis:

Using pmap: with pmap $PID | tail -1 >> mem.txt; SLEEP 0.001

Using system monitor: non scientific analysis by looking at the processes :P

 

vert.x (1 instance)

Mem (pmap): 2. 4G

Mem (System Monitor): 120M

Requests per second:   ~ 30K/s

(Added JVM flags -Xmx128m)

Mem (pmap): 446M

Mem (System Monitor): 75M

Requests per second:   ~ 30K/s

 

vert.x (4 instances)

Mem (pmap): 2. 4G

Mem (System Monitor): 120M

Requests per second:   ~ 60K/s

(Added JVM flags -Xmx128m)

Mem (pmap): 513M

Mem (System Monitor): 75M

Requests per second:   ~ 60K/s

 

vert.x (2 instances)

Requests per second:   ~ 50K/s

 

Node Server (1 process)

Mem (pmap):  ~ 640M

Mem (System Monitor): ~ 65M

Requests per second: ~ 2.6K/s

 

Node Cluster (4 processes)

Mem (pmap): ~ 640M per process ( +1 for the main process) => 3.2G

Mem (System Monitor): 4.5M + 4 * 65M => 264.5M

Requests per second: ~ 8K/s

 

Disclaimer

This is mainly for personal reference so please refrain from starting a flame war. 

I am using node.js for some current projects and really like it so this is not, by any means some node.js trashing post... just use what you like!

If you feel some of these benchmarks are unfair please perform your own and link to them in the comments... I'll gladly take a look.

Securing JS - "window.location" can we trust in it ?

We need a way to sell JS widgets and license these on a domain basis.

The idea is to provide a key which locks the widget to a given domain.

Basically we will be using window.location.host (and/or others similar like "hostname").

So, for instance  if we do

window.location.host == "mydomain.com"

we can lock the widget to this domain. Or can we ?

window.location.host = "localhost"

doesn't work cause the setter will cause the browser to navigate to "localhost". But what if we did (using Google Chrome):

window.location.__defineGetter__("host", function(){return "localhost";})

now window.location.host returns "localhost"!

The solution would be to use __lookupGetter__

window.location.__lookupGetter__("host")

If you call this before defining you own getter you get "undefined" but after defining the getter it returns a function. This way you can see if they tampered with the getter.

But what if they did

window.location.__lookupGetter__ = function(name){ return undefined;}

Now our previous method doesn't work!

We should do a 

/\[native code\]/.test(window.location.__lookupGetter__.toString())

 to make sure they haven't tampered with the __lookupGetter__ function.

Apparently Firefox doesn't provide __defineGetter__ and __lookupGetter__ for native objects like window.location so you can trust it....

We will be experimenting with this further but it just shows that JS is not to be trusted when it comes to securing your apps or widgets 

Pentaho on JBoss Portal SSO

This is mostly a reference for myself but I though it might be useful for someone...

The idea is to use JBoss Portal's authentication and authorization to control access to Pentaho. We have a legacy project and I won't be migrating to GateIn soon, although I have Pentaho working in GateIn (if you're interested get in touch with me).

I'm using Pentaho 3.7 which uses Spring Security so it is really flexible and makes it easier to integrate with custom authentication/authorization solutions.

First, thanks to this post, we'll move the portal's application policy to the server's root so it applies to all our webapps:

server/default/conf/login-config.xml :

<application-policy name="portal">
        <authentication>
           <login-module code="org.jboss.portal.identity.auth.IdentityLoginModule" flag="required">
                    <module-option name="unauthenticatedIdentity">guest</module-option>
                    <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option>
                    <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option>
                    <module-option name="userProfileModuleJNDIName">java:/portal/UserProfileModule</module-option>
                    <module-option name="membershipModuleJNDIName">java:/portal/MembershipModule</module-option>
                    <module-option name="additionalRole">Authenticated</module-option>
                    <module-option name="password-stacking">useFirstPass</module-option>
                 </login-module>

                       <login-module code = "org.jboss.portal.identity.auth.DBIdentityLoginModule" flag="sufficient">
                    <module-option name="dsJndiName">java:/PortalDS</module-option>
                    <module-option name="principalsQuery">SELECT jbp_password FROM jbp_users WHERE jbp_uname=?</module-option>
                    <module-option name="rolesQuery">SELECT jbp_roles.jbp_name, 'Roles' FROM  jbp_role_membership INNER JOIN jbp_roles ON jbp_role_membership.jbp_rid = jbp_roles.jbp_rid INNER JOIN jbp_users ON jbp_role_membership.jbp_uid = jbp_users.jbp_uid WHERE jbp_users.jbp_uname=?</module-option>
                    <module-option name="hashAlgorithm">MD5</module-option>
                    <module-option name="hashEncoding">HEX</module-option>
                    <module-option name="additionalRole">Authenticated</module-option>
                 </login-module>
                       </authentication> 
        </application-policy>

Now, enable SSO using Tomcat's Valve:

server/default/deploy/jboss-web.deployer/server.xml:

<valve className="org.apache.catalina.authenticator.SingleSignOn" />

Set the security domain in Pentaho to portal:

server/default/deploy/pentaho.war/WEB-INF/jboss-web.xml:

<security-domain>java:jaas/portal</security-domain>

Now, add the relevant security rolet to pentaho's webapp. This will be used by our preauth filter to get the roles of the Principal. We could probably create our own roles retriever but I'm just using a WebXmlMappableAttributesRetriever

server/default/deploy/pentaho.war/WEB-INF/web.xml:

<security-role> 
    <role-name>User</role-name> 
  </security-role> 
    <security-role> 
    <role-name>Admin</role-name> 
  </security-role> 
  <security-role> 
    <role-name>Authenticated</role-name> 
  </security-role>

Remove securityContextHolderAwareRequestFilter and add a j2eePreAuthFilter before authenticationProcessingFilter:

pentaho-solutions/system/applicationContext-spring-security.xml:

<bean id="j2eePreAuthFilter" class="org.springframework.security.ui.preauth.j2ee.J2eePreAuthenticatedProcessingFilter">
        <property name="authenticationManager" ref="authenticationManager" />
        <property name="authenticationDetailsSource" ref="authenticationDetailsSource" />
    </bean>
    
      <bean id="preAuthenticatedAuthenticationProvider" class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
        <property name="preAuthenticatedUserDetailsService" ref="preAuthenticatedUserDetailsService" />
    </bean>
    
     <bean id="preAuthenticatedUserDetailsService" class="org.springframework.security.providers.preauth.PreAuthenticatedGrantedAuthoritiesUserDetailsService" />
     
     <bean id="authenticationDetailsSource" class="org.springframework.security.ui.preauth.j2ee.J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource">
        <property name="mappableRolesRetriever" ref="j2eeMappableRolesRetriever" />
        <property name="userRoles2GrantedAuthoritiesMapper" ref="j2eeUserRoles2GrantedAuthoritiesMapper" />
    </bean>
    
    <bean id="j2eeUserRoles2GrantedAuthoritiesMapper" class="org.springframework.security.authoritymapping.SimpleAttributes2GrantedAuthoritiesMapper">
            <property name="convertAttributeToUpperCase" value="false" />
            <property name="attributePrefix" value="" />
    </bean>

        <bean id="j2eeMappableRolesRetriever" class="org.springframework.security.ui.preauth.j2ee.WebXmlMappableAttributesRetriever">
        <property name="webXmlInputStream"><bean factory-bean="webXmlResource" factory-method="getInputStream" />
    </property>
    </bean>
    
    <bean id="webXmlResource" class="org.springframework.web.context.support.ServletContextResource">
        <constructor-arg ref="servletContext" />
        <constructor-arg value="/WEB-INF/web.xml" />
    </bean>

    <bean id="servletContext" class="org.springframework.web.context.support.ServletContextFactoryBean" />
    
        <bean id="authenticationManager" class="org.springframework.security.providers.ProviderManager">
                <property name="providers">
                        <list>
                            <ref bean="preAuthenticatedAuthenticationProvider" />
                                <ref bean="daoAuthenticationProvider" />
                                <ref local="anonymousAuthenticationProvider" />
                        </list>
                </property>
        </bean>

 

And that should work, allowing any JBoss Portal User to get access to Pentaho. I'm using Form based authentication and have 

<security-constraint>
      <web-resource-collection>
         <web-resource-name>Authenticated</web-resource-name>
         <description></description>
         <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>Authenticated</role-name>
      </auth-constraint>
   </security-constraint>

in my jboss/server/default/deploy/jboss-portal.sar/portal-server.war/WEB-INF/web.xml. So any user which is logged in gets the Authenticated role which, fortunatelly, maps nicely to the roles in Pentaho.

We can create new roles easy, just add the, to the security roles in pentaho's WEB-INF since the role mappes just goes through these and figures out if the user has that role.

 

JAAS

I will probably also try to get direct login to Pentaho working with JAAS so these are a couple of notes I've got on that:

Add a jaasAuthenticationProvider,,,

pentaho-solutions/system/applicationContext-spring-security.xml:

<bean id="authenticationManager" class="org.springframework.security.providers.ProviderManager">
                <property name="providers">
                        <list>
                            <ref bean="preAuthenticatedAuthenticationProvider" />
                            <ref bean="jaasAuthenticationProvider" />
                                <ref bean="daoAuthenticationProvider" />
                                <ref local="anonymousAuthenticationProvider" />
                        </list>
                </property>
        </bean>

    <bean id="jaasAuthenticationProvider" class="org.springframework.security.providers.jaas.JaasAuthenticationProvider">
        <property name="loginConfig">
            <value>auth.conf</value>
        </property>
        <property name="loginContextName">
            <value>pentaho</value>
        </property>
        <property name="callbackHandlers">
            <list>
            <bean class="org.springframework.security.providers.jaas.JaasNameCallbackHandler" />
            <bean class="org.springframework.security.providers.jaas.JaasPasswordCallbackHandler" />
            </list>
        </property>
        <property name="authorityGranters">
            <list>
              <ref bean="jaasAuthorityGranter" />
            </list>
        </property>
    </bean>        

    <bean id="jaasAuthorityGranter" class="pt.inevo.pentaho.jaas.JaasAuthorityGranter" />

When using JAAS we'll be performing the queries to java:/PortalDS and since we have different Hibernate versions we get into trouble. I haven't done much work regarding this issue but changing the libs in the JBoss server should work.

Also a couple of issues with the query AST might come up so use:

 

server/default/deploy/ejb3.deployer/META-INF/persistence.properties:

hibernate.bytecode.provider=cglib</code></p>

 

Emscripten - an LLVM-to-JavaScript compiler

Emscripten is an LLVM-to-JavaScript compiler. It takes LLVM bitcode (which can be generated from C/C , using llvm-gcc or clang, or any other language that can be converted into LLVM) and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run).

Demos:

  • Python - CPython compiled to JavaScript. Note: Currently broken in Firefox 4 (may crash your browser)
  • Bullet physics - The Bullet physics engine, combined with WebGL rendering
  • Ray tracing - A simple C ray tracer, rendering to a canvas element
  • Lua - The Lua interpreter.

A letter to the Notion Ink EAP Team

Dear EAP team,

We, at inEvo, were fortunate to be selected by Notion Ink to be part of the Early Access Program Phase 2 back in late November 2010.

We made a commitment to you to not disclose any information about our selection, the process involved and other related details with anyone. As such we've refrained to posting comments in both our and your blogs.

Expectations were high as we'd be getting access to the Software Development Kit in the 1st Week of December, receiving a Customized Sample Device by the 3rd week of December and also getting a URL and other details for booking our EAP samples, with a little customization which you could do according to our needs.

On December 9th we read in your blog (thanks for the heads up) that preorders would be available from 00:00 to 06:00 IST. So we got in touch with you in order to get the URL beforehand.
All went as expected and you quickly replied us only 2 days later, on December 12th, that we could just use the pre-order link to place our orders, like everyone else.

Since we got this very personalized message, despite knowing that all the PixelQ equiped units - which is what we wanted - were already sold out ,we promptly replied to you asking for 2 Notion Ink's with the Pixel Qi screen and WiFi.

It's been two months and still nothing... We're now on 2011 and only a couple of weeks from the release of several Honeycomb based tablets  ( well, at least one ) and would like to thank you for preventing us from jumping too soon and making a wrong call regarding our tablet of choice.

Notion Ink set apart from the competition thanks to the transparency of the development process and the friendly community around it. Had we known better we wouldn't have applied for the EAP and would just have commented like there was no tomorrow in your posts.

The lesson was learnt!

Thank you,

    Nelson Silva 

Sammy

Sammy is a tiny javascript framework built on top of jQuery. It’s RESTful Evented JavaScript. Not only does it allow you to respond to specific URLs, but utilizing the URL hash (#) you can create single page applications that still respond to the back button in your browser (ala Gmail).

 

The disposable academic - Why doing a PhD is often a waste of time

This article from the Economist is a must for all involved in academic work. With sentences like "universities have discovered that PhD students are cheap, highly motivated and disposable labour" or "Writing lab reports, giving academic presentations and conducting six-month literature reviews can be surprisingly unhelpful in a world where technical knowledge has to be assimilated quickly and presented simply to a wide audience" critics compare research doctorates to Ponzi or pyramid schemes