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