martes, 26 de abril de 2016

Docker (docker-machine) build and disk space notes (Windows)

Docker Toolbox version: 1.10.3
Docker info server version: 1.10.3
Operating System: Boot2Docker 1.10.3
Windows: 7

Working with somewhat big images, I started receiving disk space errors when running docker build ("no space left on device" when executing ADD, etc.). Although my images are big, I knew they're not that big to fill the default 20GB Docker Machine Virtual Box VM disk (located in C:\Users\[User]\.docker\machine\machines\default), so before resizing its VirtualBox vmdk file, I started looking around.


I ssh'ed to the docker-machine host:

docker-machine.exe ssh


Tracing the wasted disk space (df -k, du -sh *,...) I ended up in the /mnt/sda1/var/lib/docker/tmp directory.


(note: the screenshots doesn't reflect the actual disk space in the problem's instant).

The docker user doesn't have permissions to see that directory, so you need to sudo sh.



I noticed several large docker-builder* directories storing the context for building some of my images (the Dockerfile and installers and assets needed by the build, etc....). After doing some tests building images, I noticed this directory is really a temporary directory (duh) and should not contain those docker-builder* folders if you are not actually building images (as I was not at the moment).

I deleted the folders, re ran the builds and they finished without space problems.

What caused docker not removing those temporary directories automatically? Maybe some Ctrl-C's I did when just "Sending build context to Docker daemon..." or interrupted builds?

martes, 16 de febrero de 2016

OSB 12c: "No acceptable representation for response..." invoking REST service

Error: No acceptable representation for response with "application/xml; charset=iso-8859-1" media type was found

service> AbstractResponseMessage.getPart, com.bea.alsb.ws.codec.
CodecException: No acceptable representation for response with "application/xml; charset=iso-8859-1" media type was found
com.bea.alsb.ws.codec.CodecException: No acceptable representation for response with "application/xml; charset=iso-8859-1" media type was found
        at com.bea.wli.sb.service.handlerchain.handlers.OutboundRestHandler$AbstractResponseMessage.getPart(OutboundRestHandler.java:373)
        at com.bea.wli.sb.service.handlerchain.handlers.OutboundRestHandler$AbstractResponseMessage.getPart(OutboundRestHandler.java:316)
        at com.bea.alsb.ws.codec.internal.runtime.soap.SoapDocCodec.marshallBody(SoapDocCodec.java:67)
        at com.bea.alsb.ws.codec.internal.runtime.soap.SoapCodec.marshall(SoapCodec.java:147)
        at com.bea.alsb.ws.codec.internal.runtime.soap.SoapDocClientCodec.marshall(SoapDocClientCodec.java:58)
        at com.bea.wli.sb.service.handlerchain.handlers.OutboundRestHandler.handleResponse(OutboundRestHandler.java:208)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler$1.handleResponse(AbstractHandler.java:307)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler.handleResponse(AbstractHandler.java:139)
        at com.bea.wli.sb.service.handlerchain.handlers.OutboundMessageContentHandler.handleResponse(OutboundMessageContentHandler.java:89)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler$1.handleResponse(AbstractHandler.java:307)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler.handleResponse(AbstractHandler.java:139)
        at com.bea.wli.sb.service.handlerchain.handlers.LoadBalanceFailover$LoadBalanceFailoverHelper.handleResponse(LoadBalanceFailover.java:475)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler.handleResponse(AbstractHandler.java:139)
        at com.bea.wli.sb.service.handlerchain.handlers.UpdateOutboundStatistics.handleResponse(UpdateOutboundStatistics.java:89)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler$1.handleResponse(AbstractHandler.java:307)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler.handleResponse(AbstractHandler.java:139)
        at com.bea.wli.sb.service.handlerchain.handlers.EndpointManagementHandler.handleResponse(EndpointManagementHandler.java:122)
        at com.bea.wli.sb.service.handlerchain.handlers.AbstractHandler$1.handleResponse(AbstractHandler.java:307)
        at com.bea.wli.sb.service.handlerchain.handlers.TransportProviderInvoker$ServiceTransportListener.onReceiveResponse(TransportProviderInvoker.java:302)
        at com.bea.wli.sb.transports.http.wls.rest.RestOutboundMessageContext$Reply.run(RestOutboundMessageContext.java:467)
        at weblogic.work.WorkAreaContextWrap.run(WorkAreaContextWrap.java:55)
        at weblogic.work.ContextWrap.run(ContextWrap.java:40)
        at com.bea.alsb.platform.weblogic.WlsWorkManagerServiceImpl$WorkAdapter.run(WlsWorkManagerServiceImpl.java:194)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
>

This error can be caused by a mismatch between the type of response you specified in the adapter and the real response the REST service is returning.

For example, if you specified that the service returns HTTP 200 OK with a JSON body, but the service returns just HTTP 200K withouth payload (body).



OSB: 12.1.3


viernes, 29 de enero de 2016

Exitvalue 71 starting WebSphere MQ 8 QM

WebSphere MQ for Windows (x64 platform): 8.0.0.4

If you look at the Windows Event Viewer, you will find a more detailed error detail (hopefully) referencing an FDC file in:

C:\ProgramData\IBM\MQ\qmgrs\[QM name]\errors

Look at the file header of the FDC; in my case, the problem was a "file access denied":



Looking carefully you can find more detailed information below:



Filename of stanza file passed to fopen: C:\ProgramData\IBM\MQ\qmgrs\LOCAL_QM\qmstatus.ini. strerror from fopen: Permission denied.




jueves, 28 de enero de 2016

Java, middleware, programming and general tech twitter accounts to follow







JBoss and Netbeans: enable listen on all network interfaces


Append -Djboss.bind.address=0.0.0.0 to JBoss' VM Options.



(JBossAS [6.1.0.Final "Neo"]).

martes, 3 de noviembre de 2015

Trying "Continuous Enterprise Development in Java" using Forge 2

Book: Continuous Enterprise Development in Java - Testable Solutions with Arquillian (1st Edition)

Environment:
  • JBoss Developer Studio 9.0.0.GA (Forge 2.19.2.Final - embedded)
Commands:

Forge 1: set ACCEPT_DEFAULTS true;
Forge 2: ?

Forge 1: new-project --named feedback --topLevelPackage org.x --projectFolder feedback;
Forge 2: project-new --named feedback --topLevelPackage org.x;

Forge 1: persistence setup --provider HIBERNATE --container JBOSS_AS7;
Forge 2: jpa-setup --provider Hibernate --container JBOSS_AS7;

Forge 1: validation setup --provider HIBERNATE_VALIDATOR
Forge 2: (automatically done on first constraint-add?)

Forge 1: entity --named FeedbackEntry;
Forge 2: jpa-new-entity --named X;

Forge 1: field string --named x;
Forge 2: jpa-new-field --type String --named x;

Forge 1: constraint NotNull --onProperty x;
Forge 2: constraint-add --constraint NotNull --onProperty x;

Forge 1: scaffold setup
Forge 2: scaffold-setup

Forge 1: scaffold from-entity org.x.*;
Forge 2: scaffold-generate --targets org.x.*;

Forge 1: forge install-plugin arquillian
Forge 2: addon-install-from-git --url https://github.com/forge/addon-arquillian.git --coordinate org.arquillian.forge:arquillian-addon (from here)

Forge 1: arquillian setup --containerType REMOTE --containerName JBOSS_AS_REMOTE_7.X --testframework
Forge 2: arquillian-setup (the command only accept two parameters: arquillianVersion and testFramework; the rest of information will be prompted in interactive mode) (Forge commands are contextual, so remember to cd to your app root or other convenient place to execute arquillian-setup; otherwise you may get "Command: arquillian-setup was not found")


Forge 1: arquillian create-test --class org.x.X.java
Forge 2: arquillian-create-test --targets org.x.X 

Forge 1: build --notest --profile arq-jboss_as_remote_7.x;
Forge 2: build --notest --profile arquillian-jbossas-remote-7; (build --profile doesn't support tab completions...neither build itself?)

Forge 1: forge install-plugin jboss-as-7
Forge 2: (from here)
  • addon-install-from-git --url https://github.com/forge/as-addon  --coordinate org.jboss.forge.addon:as
  • addon-install-from-git --url https://github.com/forge/jboss-as-addon  --coordinate org.jboss.forge.addon:jboss-as-as7

When I executed the last commands from the JBDS' Forge, I got the following error:

***ERROR*** Addon org.jboss.forge.addon:as,2.0.0-SNAPSHOT could not be installed: zip file closed

I had also a standalone Forge 2 (2.20.0.Final) installation. I ran the commands from there and the installation was succesful; the addons installed through that shell now appear in the addon-list of the JBDS' Forge:
  • org.jboss.forge.addon:as,2.0.0-SNAPSHOT
  • org.jboss.forge.addon:jboss-as-as7,2.0.0-SNAPSHOT
Forge 1: as7 setup
Forge 2: as-setup --server jbossas7

Forge 1: as7 start --jboss-home target/jboss-as-dist/jboss-as-7.1.1.Final/
Forge 2: as-start

JBoss Developer Studio 9.0.0.GA runs on Java 8 but JBoss AS 7 doesn't (needs Java 7). What happened to me was that JBoss AS 7 never started; it just hanged in the boot process, causing Forge to report an error after 90 seconds:

[jbds]$ cd feedback\
[feedback]$ as-start 
08:44:21,383 INFORMACIÓN [org.jboss.modules] JBoss Modules version 1.1.1.GA
08:44:21,586 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
08:44:21,649 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
***ERROR*** JBoss Application Server 7.1.1.Final has failed to start. Error: Managed server was not started within [90] s
[feedback]$ 

What I did was to create a batch script to set JAVA_HOME to a JDK 7 before launching jbdevstudio.exe:


This way, JBDS continues using Java 8:


But AS 7 starts with Java 7:


(Tool: MS Process Explorer)





Tips:

  • If JBDS begins starting without asking for workspace (just using a default workspace), you can use jbdevstudio.exe -clean to force it to start asking for workspace each time.