Migrazione dati da PostgreSql 8.3 a 9.3

Per motivi di lavoro spesso ci si trova a cambiare il proprio pc e magari non si vorrebbero perdere i dati quando si effettua tale cambio. Anche se si disponesse dei vari comandi che servono per ricreare i database , magari si vorrebbero mantenere i dati in esso contenuti e vorremmo migrare il tutto nella maniera più rapida possibile.

Fino a quando si mantiene la stessa versione di Postgres , poratare i dati dal vecchio al nuovo pc è veramente molto semplice , si tratta solo di copiare la vecchia cartella “data” nella nostra nuova installazione Postgres (consiglio sempre di effettuare un backup della cartella prima di sostituirla).

Tuttavia, come nel mio caso, ci possiamo trovare di fronte all’impossibilità di poter reinstallare la stessa versione di database. Se  l’installazione Postgres che effettuiamo ha una versione diversa rispetto la provenienza dei nostri dati, allora non possiamo procedere  come sopra, perché la cartella “data” non è compatibile in termini di cross version, ma se disponiamo ancora della versione funzionante sul nostro vecchio pc , abbiamo ancora una possibilità di poter effettuare una rapida migrazione.

Si tratta semplicemente di procedere come segue :

1) Sul nostro vecchio PC aprire pgAdmin

2) Collegarsi al server Postgres

3) Menu->Tools->backup server

4) Specificare un nome per il nostro backup e procedere. Verrà generato un file di testo piatto con tutti i comandi sql postgres per ricreare tabelle/ruoli e dati. In realtà la stessa operazione può tranquillamente essere effettuata anche eseguendo i seguenti comandi

pg_dumpall > backup

oppure

pg_dump -U USERNAME DBNAME > dbexport.sql

potrebbe essere richiesta la password per l’accesso al vostro database

5) Portiamo il file creato nel nostro pc dove gira la nuova versione di POsgress

6) Assicuriamoci che il database sia up&running

7) Accediamo alla cartella che contiene i comandi posgres , ad esempio :

C:\Program Files\PostgreSQL\9.3\bin\

8) Eseguiamo il seguente comado :

psql -f dbexport.sql postgres

oppure

psql –username postgres –file dbexport.sql

Vi verrà richiesta l’inserimento della password che è quella che avete utilizzato in fase di installazione del vostro Postgres

9) Startate il vostro PgAdmin e verificate che tutto sia andato bene.

Se durante la fase di restore dei dati, tramite da linea di comandi (punto 8) , dovesse spuntare un messaggio di errore del tipo

Oppure

Allora basta eseguire il comando prima di eseguire il punto 8:

chcp 1252

probabilmente dovuto al fatto che la console di window utilizza un encoding differente  che potrebbe dare fastidio ad eventuali caratteri speciali che potrebbero trovarsi dentro il nostro file di backup psql.

 

https://www.postgresql.org/download/windows/

http://databasemaster.it/installare-postgresql-su-windows/

http://www.postgresqltutorial.com/install-postgresql/

https://www.postgresql.org/docs/8.3/migration.html

 

JAX-WS Esempio di Web-Service step by step

Questo post vuole semplicemente essere un banale esempio di web-service esposto su un web server Tomcat, con l’obiettivo di utilizzare steps quanto più meccanici e semplici possibili.

Piccola digressione , un web service non è altro che un servizio esposto sul web , si parla di servizio, in quanto è un’applicazione software che offre ad altre applicazioni delle funzionalità. Queste sono interrogabili tramite protocollo HTTP/HTTPs il cui payload è una richiesta SOAP. Questa accede all’interfaccia dal nostro servizio rispettando delle regole , o come si suol dire un contratto, rappresentato in gergo dal WSDL che il nostro servizio espone su un ben preciso punto di accesso , chiamato end-point.
Jax-ws, inizialmente nato come progetto a se stante, è oggi integrato nella piattaforma J2EE come l’insieme delle interfacce (API) del linguaggio di programmazione Java dedicate allo sviluppo di servizi web. Di seguito la url per avere un riferimento ufficiale: https://docs.oracle.com/javaee/6/tutorial/doc/bnayn.html

Veniamo adesso al nostro esempio :

  • Esegui il tuo Eclipse
  • Crea un nuovo progetto Maven

  • Inserire “maven-archetype-webapp” come filtro e selezionare la voce corrispondente

  • Quindi inserire un groupID e artifactID

  • Alla fine avremo creato il nostro progetto web maven vuoto

Se come nel mio caso riscontrate un problema di “Maven configuration Problem”. Probabilmente non state utilizzando la corretta versione di java . Nel mio caso dal pom si osserva :

Vado di conseguenza a modificare la versione di java tramite le preferences di Eclipse.  Se questo non è ancora sufficiente a far scomparire i Maven Configuration Problem e se compare un errore del tipo :

org.apache.maven.archiver.MavenArchiver.getManifest(org.apache.maven.project.MavenProject, org.apache.maven.archiver.MavenArchiveConfiguration)

allora è probabile che la versione di m2e di Eclipse sia obsoleta, rispetto al pom.  Si  potrebbe procedere aggiornando la versione  di Eclipse oppure è possibile scaricare una versione più aggiornata del plugIn, ad esempio al seguente url :

https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/

  • A questo punto , possiamo cercare sul repository maven una delle ultime versioni disponibili, compatibile con la versione di java che stiamo utilizzando e copiamo le dipendenze da aggiungere al pom.xm

Nella mia situazione , probabilmente per via della versione un pò vecchia di Eclipse , occorre anche escludere il seguente path , altrimenti la build di Maven  avverrà in maniera errata :

Alla fine, a livello di progetto Eclipse, arriverete alla seguente situazione :

  • Adesso siamo pronti a creare la nostra prima interfaccia come segue :

Se vogliamo un web-service che può girare sul nostro web server,  dobbiamo anche creare il file sun-jaxws.xml  al seguente path /main/webapp/WEB-INF che  fornisce le informazioni di end poit:

<endpoints xmlns=”http://java.sun.com/xml/ns/jax-ws/ri/runtime” version=”2.0″>
<endpoint name=”MyFirstWebService”
implementation=”demojaxws.MyFirstWebService”
url-pattern=”/myFirstWebService” ></endpoint>
</endpoints>

  • Modifichiamo il file web.xml  :

  • Eseguite la maven build :

  • A questo punto non ci resta altro che deployare il nostro web-service su Tomcat.

Io utilizzerò un Tomcat 7 e per comodità procederò alla creazione del server Tomact sotto Eclipse come segue :

Una volta pubblicato il servizio , eseguiamo lo start del nostro server  ed accediamo al nostro web-server tramite il seguente puntamento :

http://localhost:8080/myJaxWS/myFirstWebService

Oppure possiamo accedere al wsdl per creare la nostra prima request  tramite il seguente puntamento :

http://localhost:8080/myJaxWS/myFirstWebService?wsdl

Per semplicità io utilizzo un soap client come XmlSpy per creare la soap request , ma si potrebbe utilizzare un qualsiasi altro client , come ad esempio la versione free di SoapUI.

Nel caso del client da me utilizzato :

Specifico il wsdl del servizio

seleziono il metodo che il servizio espone

viene creata una richiesta standard (in questo caso XMLSpay, lo fa in automatico per voi , perchè è in grado di decifrare le regole del vostro wsdl)

quindi possiamo direttamente inviare la richiesta al web server come segue

Di seguito la request Soap e la corrispondente risposta che il servizio ci fornisce

Soap Request :

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <SOAP-ENV:Body>
  <m:sayHello xmlns:m="http://demojaxws/">
   <guestname xsi:type="xsd:string">Maurizio</guestname>
  </m:sayHello>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Soap Response :

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
 <S:Body>
  <ns2:sayHelloResponse xmlns:ns2="http://demojaxws/">
   <return>Hello Maurizio</return>
  </ns2:sayHelloResponse>
 </S:Body>
</S:Envelope>

JVM strumenti di diagnostica

jcmd

Spesso, quando viene realizzata un’applicazione, sarebbe buona abitudine effettuare i necessari tests di performance ,  endurance e  stress, in modo da rilevare eventuali punti critici o di miglioramento prima che l’applicazione , come si dice in gergo, venga messa in produzione. Nel caso di un’applicazione Java, occorre poter interagire con la JVM. Esistono diversi tolls e/o utility, uno di questi è jcmd che viene utilizzato per invocare comandi di diagnostica alla JVM (qui il riferimento ufficiale). Per scoprire i comandi che possiamo eseguire è sufficiente procedere come segue :

jcmd <pid> help

The following commands are available:
VM.native_memory
ManagementAgent.stop
ManagementAgent.start_local
ManagementAgent.start
GC.rotate_log
Thread.print
GC.class_stats
GC.class_histogram
GC.heap_dump
GC.run_finalization
GC.run
VM.uptime
VM.flags
VM.system_properties
VM.command_line
VM.version

In realtà, la disponibilità di un comando, piuttosto che un altro, dipende anche dalla JVM su cui operiamo (in questo caso si tratta di openjdk-1.8.0.77-0).

Un comando  molto utile è il seguente :

jcmd <pid> VM.system_properties

ci permette di visionare tutte le system properties dell’applicativo che gira nella jvm

jcmd <pid> GC.heap_dump /tmp/test.hprof

permette di generare il dump dello heap che possiamo dare in pasto ad eventuali tools di analisi.

Infine, un comando che, secondo me, vale la pena tenere presente è

jcmd <pid> GC.run

Questo ci permette di forzare una System.gc() all”interno della JVM ed è, quindi, utilissimo per verificare che la memoria venga effettivamente liberata a seguito di un full gc. Ovviamente, per procedere, con tale osservazione occorre abilitare la nostra JVM a stampare l’andamento del gc.log.  Questo si può banalemente attivare aggiungendo le seguenti options sulla linea di comando che istanzia la jvm :

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

JMX PORT dove si trova configurata in WildFly

Accedere al file standalone.xml.
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:500}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
.....
<socket-binding-group>

Per capire quale porta utilizzare è sufficiente aggiungere l’offset definito, nel nostro caso “500” al valore standard indicato ovvero “9990”.

Questo significa che nel nostro caso occorre utilizzare alla porta

9990+500 = 10490