This page https://github.com/immutant/immutant/blob/master/docs/guides/migration.md has a broken link to https://github.com/immutant/immutant/blob/master/docs/guides/guide-installation.html
@laujensen the links in the guides aren't consistent when read as source/from github, they are designed to be read from http://immutant.org/documentation/2.1.9/apidoc/guide-migration.html
are you migrating from 1.x?
Alright. Yeah Im trying to pull SabreCMS up from 1.1.4 to 2.19, just as a test. As Im reading the docs, the core functionality is easily moved by installing Wildfly, changing start to run, and compiling to a war right?
for web, yes, though depending on what options you are using, you may run in to issues. And you'll need to use lein-immutant
to create that war: http://immutant.org/documentation/2.1.9/apidoc/guide-wildfly.html
Yeah I just updated the plugin in and was surprised to see all my deploy, run, server, etc options were gone 🙂
yep, with 2.0 we decided to back away from managing the container for you, since you have to have knowledge about how to configure/manage WildFly anyway to use it properly in production
But @tcrawley, since you're here. The reason I started reviewing our architecture, is because we have a handler that responds in 3msecs, but when I query the page it emits, there's a wait between connection handshake and transmission of 100msecs. Do you know if thats from nginx, jboss/immutant or ring?
Hmm, I don't know where that could be. Can you hit jboss/immutant directly to eliminate nginx as a cause?
Maybe, but I hit nginx directly and there's no wait
Ist borderline nitpicking, I think Sabre is now the fastest CMS in the world, but I'd still like it to be faster
is it just one handler that is slow?
No its everything. I just highlight that because its consitently 3msecs, so I know it cant be it
I know there's some overhead of servlet handing in jboss, but it shouldn't be that high I don't think. I do know that wildfly + immutant 2 would be faster, and immutant 2 standalone (w/o wildfly) is even faster, if using that is an option for you
I wasnt aware of a version2 without wildfly, have a link? I'll test it out
running Immutant w/o the container is now the default (and most commonly used) way to do it. See http://immutant.org/documentation/2.1.9/apidoc/guide-installation.html for a walkthrough, and I'm happy to answer any other questions
Thanks! So ideally, thats my setup for dev, and on the servers I'll set up Wildfly containers for easier management right?
it depends - do you deploy multiple instances in the same wildfly? If not, you may not need WildFly in there at all, just an uberjar
are you using more services than web?
but yes, you should be able to dev locally w/o WF
Ok - Ive never used wildfly before. We're looking to move to AWS where multiple, but separate, shards of the app will be started. I dont think we need any added management for that
even if you deploy to it
Currently just web. Have been looking at messaging
Did you link the right page? Its mostly about Wildfly
WildFly is just JBoss AS renamed, so should be familiar
ah
http://immutant.org/documentation/2.1.9/apidoc/guide-installation.html? It mentions WildFly briefly, but the important section there is the one talking about running from a :main
basically, you just create a -main
function that calls immutant.web/run
, set that as your :main
in project.clj
, then call lein run
. No WildFly required
or call that main from the repl
Ok thanks @tcrawley - Thats every similar to how 1.1.4 is structured
@tcrawley So I wrapped my call to web/run in a (defn -main [] (web/run routes)) and added that + deps to project.clj. Everything seems to boot, even from the main namespace (ie Im seeing services start), but then the log just says Cannot find anything to run for :main
Does that make sense to you?
That doesn't ring a bell. how are you starting it? and what does the :main
entry in project.clj
look like?
:main immutant.init/main
(ns immutant.init
(:use tigerbyte.core)
(:require
[immutant.web :as web])
(:gen-class))
(defn -main
[]
(web/run "/" routes))
you're seeing services start - does that mean that undertow is starting on 8080 even with that message?
and is that message part of an exception that causes the app to exit?
I'll have a log. I see also logging has been set to DEBUG so Datomic is cluttering the logs
All handlers are timing out, but server is still running
ah, logging. that's always fun. You may have to adjust the configuration to hide those DEBUG messages. See http://immutant.org/documentation/2.1.9/apidoc/guide-logging.html#h3339
can you share the full log output? you can send that to me privately if need be
Yes, one quick before: Is the util namespace in its own dependency ?
immutant.util
is in org.immutant/core
, which should be brought in transitively by org.immutant/web