Baratine 0.8.7

48 views
Skip to first unread message

Scott Ferguson

unread,
Jan 13, 2015, 3:03:10 PM1/13/15
to barat...@googlegroups.com
Baratine 0.8.7 is available.

http://baratine.io/download/baratine-0.8.7.tar.gz
(maven) http://caucho.com/m2

Release notes at
http://doc.baratine.io/v0.8/manual/release-notes/0.8/0.8.7
JavaDoc: http://baratine.io/javadoc-0.8/


Main changes are deployment and node/pod API.

The deployment is now more cleanly integrated with BFS.

The main deployment files are in bfs:///config/pods/<pod-name>.cf, and
control the deployment process. The bfs:///config/pods is now the
authoritative source for pod configuration.

1. Each *.cf specifies one or more pods and one or more application
libraries.

2. Uploaded .jar/.bar files are in bfs:///usr/lib by convention.

3. The cluster pod manager (bartender), parses all the *.cf files and
creates appropriate pods across the cluster. (This phase ignores
application configuration and jar files.)

4. When a pod node starts on a server, it parses the *.cf files, looking
for its own configuration. It will expand and deploy the jar/bar files
specified by the *.cf file.

To debug/troubleshoot:

$ bin/baratine ls /config/pods
... # list of the deployed configuration files

$ bin/baratine cat /config/pods/pod.cf
... # verify the pod configuration

$ bin/baratine ls /usr/lib
... # verify uploaded jar/bar

$ bin/baratine get /usr/lib/pod.bar pod.bar
... # verify uploaded jar/bar

$ bin/baratine cat /proc/pods
... # verify deployed pods

$ bin/baratine cat /proc/services
... # verify deployed services on the current server

-- Scott

Riccardo Cohen

unread,
Jan 14, 2015, 6:14:53 AM1/14/15
to barat...@googlegroups.com
Thanks a lot for this new version.
This is the results of my new tests with 0.8.7 :

- undeploy works all right now with default pod.

- when I update my jar, it seems that I need to undeploy before calling
deploy, if not I have some log INFO like "RealtyUserList.jar time is
modified.". Maybe this is a normal behaviour.

- deploying several jars works only if each jar is on a different pod,
maybe this is a normal behaviour.

Please notice that in this situation, undeploy does not work because
there is no --pod option in undeploy, and the jar is not removed from
the pod

- when I call put() to update a node, the node is updated in memory, and
the get() returns the new value. but after a start/stop or
undeploy/deploy, the previous data is back, it seems that it is not
stored on disc

- there is still an exception with delete :

[2015-01-14 10:18:19,816] WARNING DeliverInbox:
DeliverInbox[ActorSkeletonBean[ResourceManagerImpl[User]]]
java.lang.NullPointerException
java.lang.NullPointerException
at
com.caucho.kraken.query.DeleteQuery$FindDeleteResult.complete(DeleteQuery.java:127)
at
com.caucho.kraken.query.DeleteQuery$FindDeleteResult.complete(DeleteQuery.java:116)
at com.caucho.kelp.TableKelp.findOne(TableKelp.java:497)
at com.caucho.kraken.query.DeleteQuery.exec(DeleteQuery.java:104)
at
com.caucho.amp.resource.TableResourceService.delete(TableResourceService.java:135)
at com.caucho.amp.resource.ContextResource.delete(ContextResource.java:361)
at
com.caucho.amp.resource.ActorSkeletonResource.delete(ActorSkeletonResource.java:144)
at
com.caucho.amp.proxy.FilterMethodDelete.delete(FilterMethodDelete.java:128)
at com.caucho.amp.proxy.FilterMethodDelete.send(FilterMethodDelete.java:63)
at com.caucho.amp.actor.MethodAmpBase.send(MethodAmpBase.java:120)
at com.caucho.amp.actor.MethodAmpChild.send(MethodAmpChild.java:65)
at com.caucho.amp.actor.ActorAmpBase.send(ActorAmpBase.java:157)
at com.caucho.amp.message.SendMessage_0.invoke(SendMessage_0.java:49)
at com.caucho.amp.inbox.DeliverInbox.deliver(DeliverInbox.java:117)
at com.caucho.amp.inbox.DeliverInbox.deliver(DeliverInbox.java:50)
at com.caucho.amp.queue.QueueRing.deliver(QueueRing.java:293)
at
com.caucho.amp.queue.QueueRingResizing.deliver(QueueRingResizing.java:219)
at
com.caucho.amp.queue.WorkerDeliverSingleThread.runImpl(WorkerDeliverSingleThread.java:82)
at
com.caucho.amp.queue.WorkerDeliverBase.runStarted(WorkerDeliverBase.java:243)
at com.caucho.amp.queue.WorkerDeliverBase.run(WorkerDeliverBase.java:167)
at com.caucho.amp.thread.ThreadAmp.runTasks(ThreadAmp.java:187)
at com.caucho.amp.thread.ThreadAmp.run(ThreadAmp.java:158)




Thanks for any help. (attached my source code)
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
16 rue de Belle Isle
37100 Tours
France

<http://www.paragence.fr>
User.java
UserList.java

Scott Ferguson

unread,
Jan 14, 2015, 6:59:32 PM1/14/15
to barat...@googlegroups.com
On 1/14/15 3:14 AM, Riccardo Cohen wrote:
> Thanks a lot for this new version.
> This is the results of my new tests with 0.8.7 :
>
> - undeploy works all right now with default pod.

Good.
>
> - when I update my jar, it seems that I need to undeploy before
> calling deploy, if not I have some log INFO like "RealtyUserList.jar
> time is modified.". Maybe this is a normal behaviour.

That's normal. Baratine logs the update so you'll know why the PodApp
restarted.

>
> - deploying several jars works only if each jar is on a different pod,
> maybe this is a normal behaviour.

You can put multiple jars on the command line. Or you can package them
into a .bar file.

The structure of the .bar is:
lib/*.jar

>
> Please notice that in this situation, undeploy does not work because
> there is no --pod option in undeploy, and the jar is not removed from
> the pod
The undeploy argument should be the pod name.

What actually happens with the undeploy is that the config/pods/<pod>.cf
is removed.
>
> - when I call put() to update a node, the node is updated in memory,
> and the get() returns the new value. but after a start/stop or
> undeploy/deploy, the previous data is back, it seems that it is not
> stored on disc

I wasn't able to duplicate this.

I did notice that the HTTP PUT/DELETE isn't properly implemented. I've
updated those for the next release.

The model for PUT is different than your example. It should be:

void put(User user)

That will let you give the JSON for the User contents as the PUT body.


>
> - there is still an exception with delete :
>
> [2015-01-14 10:18:19,816] WARNING DeliverInbox:
> DeliverInbox[ActorSkeletonBean[ResourceManagerImpl[User]]]
> java.lang.NullPointerException

Ok. I've fixed these. There are additional issues with the delete that
I've also fixed.

-- Scott

Riccardo Cohen

unread,
Jan 20, 2015, 4:02:54 AM1/20/15
to barat...@googlegroups.com
Hello Scott
Thanks for the answer.

> The undeploy argument should be the pod name.

does not work. I've added a jar with

deploy --pod realtyuserlist /Users/rc/...../RealtyUserList.jar

and called

undeploy realtyuserlist

the application still answers to requests. The jar is still in
baratindir/data-8085/pods/realtyuserlist.0/lib and in BFS :
/config/pods/realtyuserlist.cf is still there

undeploy RealtyUserList.jar does not work either.

But the undeploy command works if I use the default pod name="pod" :

deploy /Users/rc/...../RealtyUserList.jar
undeploy pod


> The model for PUT is different than your example. It should be: void
put(User user)

I changed the call and set User as argument everywhere from javascript
to java. Same problem : the new data is lost after stop/start.

code attached
Thanks
User.java
UserList.java
Reply all
Reply to author
Forward
0 new messages