ATI Radeon 2600 drivers on Ubuntu 12.04.02 with 3.5.0-32 kernel

I just spent a few hour trying to install proprietary drivers on my (old) laptop for my (old) graphic card.
If the following configuration talks to you, then I might help you :-)

- Ubuntu 12.04.02
- Kernel version 3.5.0-32-generic
- ATI Radeon 2600 graphic card

Since the last kernel update, unable to install Catalyst 13.1 drivers. dpkg creation is successful, but when trying to install those dpkg I am getting a bad exception when fglrx is installing.

Error! Bad return status for module build on kernel: 3.5.

DKMS part of installation failed. Please refer to /usr/share/ati/fglrx-install.log for details

Same result with the graphic installer of course.

After a while I found some 13.4 Catalyst drivers. Installation goes smoothier, but in the end...

aticonfig: No supported adapters detected 

Arrrgh ! They dropped support for 2600 series in this version !

Only solution that worked for me :
https://launchpad.net/~makson96/+archive/fglrx

Hope this help !

Concurrent calls in Axis 1.4 : thread safety issue

I had to deal with concurrent calls issue in Axis 1.4.
After googling a bit, it turns out that some guys from axis crew state the following :
- Generated service locators are thread safe
- However, ports stubs retrieved from those locators are NOT thread safe !

So even if the stubs look designed to be reused (they're caching bits of request for performance matter I suppose), that's really a bad idea to do so.

I wanted to know where exactly the problem was, so I dove into the sources, and here is what I found.

Let's suppose I retrieve my stub this way :

axisGeneratedProxy.getMyGeneratedWSStub().theMethodToCall([some Params]);

In the theMethodToCall method, you'll find the following :

org.apache.axis.client.Call _call = createCall();
_call.setOperation(_operations[2]);
_call.setUseSOAPAction(true);
...

If you go up the hierarchy a little, you'll find out that the createCall method is returning a call object generated from the org.apache.axis.client.Stub class. This call object is generated this way :

public abstract class Stub implements javax.xml.rpc.Stub {
 ...
 // The last call object
 protected Call _call = null;public Call _createCall() throws
 ...
   /**
      * Creates a call from the service.
      * @return
      */
     public Call _createCall() throws ServiceException {
         _call = (Call) service.createCall();
          // TODO: There is a lot of code in the generated stubs that
         // can be moved here.
         return _call;
     }
 ...
 }

So what do we have here ? The generated call object is stored temporarly in a _call class attribute. If concurrent threads T1 and T2 get mixed up in this method, we'll end up with both threads sharing the same call object.

So, back to the stub code.

After getting back this call object, it's filled with data. Here, both threads will manipulate the same object, so potentially some data will get mixed up... but as we're in a stub method, that should be the same data so it doesn't really bother.

But the real problem occurs later in the call.invoke() method : when adding the body element to the message, the following private method is used :

 public void addBodyElement(SOAPBodyElement element)
    {
        if (body == null) {
            body = new SOAPBody(this, soapConstants);
        }
        element.setEnvelope(this);
        body.addBodyElement(element);

        _isDirty = true;
    }

Here the body attribute is a class attribute... If two or more threads get mixud up here, the stub sharing the same call element, the two calls will go to the server with the same body element...

Solution : use many stubs, don't reuse one !

Google Chrome initiating a google search for local urls with dots in it

I tend to modify my hosts file whenever I'm working on a project : it sometimes help to detect bugs (javascript related mainly).

Problem is, with Google Chrome, when I was typing local.something:8080 in the address bar, the browser would launch a Google search on that address - which is obviously not what I want.

After googling a bit, looks like turning off DNS prefetch does the trick : indeed now Chrome just load my local web page instead of searching on Google.

You can access this property in the browser settings. You have to display advanced settings.
(Below a snapshot - that's in french but hey - I guess you'll find the correct option)

Java Memory in open VZ machines

Hi,

I ran into troubles while trying to run a play application. The server is hosted in an openVZ container, which lead to problems during jvm memory initialization when I entered à play start command :

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

After googling a while, this SO thread gave me the answer which I'll summarize here.

If you're in a hurry, here is the answer : edit the [JRE location]/lib/[Archi (ex : i386)]/jvm.cfg file and alter the first uncommented line.

Move from

-client IF_SERVER_CLASS -server
-server KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR

to:

#-client IF_SERVER_CLASS -server
-client KNOWN
-server KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR

From what I understand, with the initial configuration, when trying to launch a java process if the machine has 2G+ memory installed  it fires up the JVM in server mode.
Server mode means the JVM will ask for all the memory requested in contiguous memory blocks, and openVZ is not able to do that.

The -client KNOWN option will ask for memory on the fly, thus removing the problem meentionned above.

Hope this help.

Yeoman : TypeError('Arguments to path.join must be strings');

Edit : Node 0.10 is now fully supported (working with a 0.10.17 right now) - keeping the old thread for archive. However, I had the error described below with the default Ubuntu 12.04 LTS node version (0.11-pre something) 


Hi all,

Today I was playing with this great Yeoman tool. Basically it's a scaffolding tool (yo) combined with a building (grunt) and dependency manager tool (bower) for building front end apps.

That tool (or that tooling set) is really, really great and you should check it out.

Set up is really easy, everything is packaged as Node.js modules. Only thing I didn't see first when installing the stack : Node.js is fully supported until version 0.8.x for now. Running a higher version (0.10 in my case) will lead to problems like this

path.js:360
        throw new TypeError('Arguments to path.join must be strings');
              ^
TypeError: Arguments to path.join must be strings
    at path.js:360:15
    at Array.filter (native)
    at Object.exports.join (path.js:358:36)
    at Object. (/opt/nodejs/node-v0.10.0-linux-x64/lib/node_modules/yo/node_modules/yeoman-generator/node_modules/bower/lib/core/config.js:41:22)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)

This error doesn't come right away, I had it when trying to use the angular generator (angular:route) to be precise.

Hope this help.

Linux : look for a string pattern in files in a particular directory and sub directories

Say you want to search for a string pattern in all files included in a directory, and even in its subdirectories. Well, here is the magic command :

find /directory/where/to/look/for -exec grep -nH "my string to look for" {} \;

The command is pretty self explanatory :

/directory/where/to/look/for

The ditectory where you will lokk for files, including all of its sub-directories

-nH

the 'n' option will print line numbers, and 'H' file paths.

Add a number in those options, and bash will print out 'x' the x lines before and after the line matching the pattern (i.e. -nH5 will print out five lines after and before matching line)

"my string to look for"

The pattern to look for. Quotes are only mandatory if your search pattern includes spaces.

You can of course use other find and grep options, i.e. find -name *.xml to filter only xml files.

Example :

 find . -exec grep -H 10108 {} \;

./blabla.text:7:ds10108
Binary file ./jre1.6.0_21/win/bin/fontmanager.dll matches
Binary file ./jre1.6.0_21/win/lib/rt.jar matches

JAX-RS / Jersey CORS Filter and JAXB List

I had to implement CORS functionnalities for cross domain javascript in my REST app.
I stumbled upon the excellent solution posted by Usul.

Basically, you have to implement a ContainerResponseFilter that will check request headers and set response headers :

 public ContainerResponse filter(ContainerRequest req, ContainerResponse contResp) {
 
        ResponseBuilder resp = Response.fromResponse(contResp.getResponse());
        resp.header("Access-Control-Allow-Origin", "*")
                .header("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
 
        String reqHead = req.getHeaderValue("Access-Control-Request-Headers");
 
        if(null != reqHead && !reqHead.equals(null)){
            resp.header("Access-Control-Allow-Headers", reqHead);
        }
 
        contResp.setResponse(resp.build());
            return contResp;
    }

This solution worked great until I had to return a List of objects. In this particular case, the Response.fromResponse method returned a ResponseBuilder object in which I had lost my collection type, resulting in a nice exception saying that no MessageBodyWriter was found.

A message body writer for Java class java.util.ArrayList, and Java type class java.util.ArrayList, and MIME media type application/json was not found

To bypass it, instead of using the nice Response.fromResponse method, I had to set the headers "manually" in the ContainerResponse object by accessing the header map :

public ContainerResponse filter(ContainerRequest req, ContainerResponse contResp) {
  contResp.getHttpHeaders().add("Access-Control-Allow-Origin", "*");
  contResp.getHttpHeaders().add("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
  
  String reqHead = req.getHeaderValue("Access-Control-Request-Headers");

  if (null != reqHead && !reqHead.equals(null)) {
   contResp.getHttpHeaders().add("Access-Control-Allow-Headers", reqHead);
  }
  return contResp;
 }

Doing it this way, response object isn't modified and type information isn't lost. JAXB is now able to marshall json or xml either in single object or collection case of return.