Calling imageMagick in parallel crashes Lasso 9

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
Stumbled into instability when stressing ImageMagick. This is using Lasso 9 latest distro on Centos 5.8 64 bit.

We have a setup where we have image data stored in a table but also as real files on disk. When a call for a file is made the process is to first check if the file exist as a physical file. If it does, serve it. If not go fetch it from the table and, with the help of ImageMagick create the file to disk in a number of preset sizes. 67 px high, 133, 200, 266 and 640. After the image files are created, serve from disk. This all works fine and has for a long time.

But, in a setup where there're several images that are to be displayed as thumbnails on one page we're running into issues. The thumbnails are based on fairly large images that has to be big since they're used for printing as well. If they don't exist as files the process of creating all the different sizes is triggered. And since there're several images on one page the process is triggered several times in parallel. This crashes the Lasso instance and makes it restart. I can see in the log that it starts well, makes it's way thru the first, small sizes, then halts and after a moment of silence, restarts the instance.

Here's an error message that might be relevant:
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002aaab621db31, pid=10556, tid=1113266496
#
# JRE version: 6.0_22-b22
# Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.10.9
# Distribution: CentOS release 5.8 (Final), package rhel-1.28.1.10.9.el5_8-x86_64
# Problematic frame:
# C  [libMagick.so.10+0xf0b31]  log10+0xf0b31
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid10556.log

The file /tmp/hs_err_pid10556.log is amazingly large and contain nothing that makes sense for me but I can distribute it if anyone knows what to do with it.

This is caused by calls all coming from the same page and user but I imagine that the same could happen if there're several users calling for images at about the same time. In fact it could be an explanation why we're seeing occasional crashes on a production server as well.

So, what to do?
We can't rethink the logic. The reason for not just putting the files on disk to begin with is that we need to accommodate several servers working in parallel. The image could be uploaded on another server than it's retrieved from.
Me thinks that ImageMagick or possibly the JVM runs into memory issues.
Thus hoping that a fix would be to increase the JVM allocated memory. How do we do that?

Another possible route would be to make sure that the process that calls ImageMagick only does so for one image at a time. How can I setup that kind of "atomic" behavior using best practices?

Any other suggestions?

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

stevepiercy
On 2/5/13 at 12:27 PM, [hidden email] (Jolle
Carlestam) pronounced:

>So, what to do?
>We can't rethink the logic. The reason for not just putting the
>files on disk to begin with is that we need to accommodate
>several servers working in parallel. The image could be
>uploaded on another server than it's retrieved from.
>Me thinks that ImageMagick or possibly the JVM runs into memory issues.
>Thus hoping that a fix would be to increase the JVM allocated
>memory. How do we do that?

In 8, I did this to the internal SQLite database.

insert into global_prefs (`store_key`,`data`) values
("java_vm_options","-Xms8m -Xmx16m");

or update:
update global_prefs set `data` = "-Xms8m -Xmx16m" where
`store_key` = "java_vm_options";

Xms8m = minimum size 8MB
Xmx16m = maximum size 16MB

You can tweak to some power of 2 for your environment.

However, I don't think the JVM and IM are related, unless you're
doing something that requires Java, like inserting images into a
PDF.  I get several of those hs_err_foo.log files and pass them
along to LassoSoft whenever I get a severe case of the nasty crashies.

>Another possible route would be to make sure that the process
>that calls ImageMagick only does so for one image at a time.
>How can I setup that kind of "atomic" behavior using best practices?

You might find that there are more optimal ways of calling IM
from the command line.  It's hard to say without seeing your
code.  The IM docs and forums have tons of tips and tricks that
help reduce resource consumption.

--steve


>Any other suggestions?
>
>HDB
>Jolle
>#############################################################
>This message is sent to you because you are subscribed to
>the mailing list Lasso
>[hidden email]
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
5 feb 2013 kl. 13:59 skrev Steve Piercy - Web Site Builder <[hidden email]>:

>> Another possible route would be to make sure that the process that calls ImageMagick only does so for one image at a time. How can I setup that kind of "atomic" behavior using best practices?
>
> You might find that there are more optimal ways of calling IM from the command line.  It's hard to say without seeing your code.

Thanks, Steve!

Snippets from the code:

local(imagedata = image(field('file_data')))

#imagedata -> save(#filepath + #filename)
// this will save the file to disk as it was retrieved from the table.

// create all subdirs and files
local(temp_image = #imagedata -> ascopy)
#extrapath = 'h67/'
#this_dir = dir(#filepath + #extrapath)
if(!#this_dir -> exists) => {
        #this_dir -> create
}
#temp_image -> scale(-height = 67, -thumbnail)
#temp_image -> save(#filepath + #extrapath + #filename)
stdoutnl('image scaled to 67 ' + #filename)

#extrapath = 'h133/'
#this_dir = dir(#filepath + #extrapath)
if(!#this_dir -> exists) => {
        #this_dir -> create
}
#temp_image = #imagedata -> ascopy
#temp_image -> scale(-height = 133, -thumbnail)
#temp_image -> save(#filepath + #extrapath + #filename)
stdoutnl('image scaled to 133 ' + #filename)


-------
Continues the same way for all the other sizes.
When Lasso runs into trouble I get a couple of the log entries. Like:
image scaled to 67 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
image scaled to 133 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
image scaled to 200 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
image scaled to 67 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
image scaled to 67 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
image scaled to 133 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
image scaled to 67 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg
image scaled to 133 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
image scaled to 200 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
image scaled to 133 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg
image scaled to 200 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
image scaled to 200 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg

After that the instance restarts.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

stevepiercy
On 2/5/13 at 1:10 PM, [hidden email] (Jolle
Carlestam) pronounced:

>5 feb 2013 kl. 13:59 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>>> Another possible route would be to make sure that the process that calls
>ImageMagick only does so for one image at a time. How can I
>setup that kind of "atomic" behavior using best practices?
>>
>>You might find that there are more optimal ways of calling IM from the command
>line.  It's hard to say without seeing your code.
>
>Thanks, Steve!
>
>Snippets from the code:
>
>local(imagedata = image(field('file_data')))
>
>#imagedata -> save(#filepath + #filename)
>// this will save the file to disk as it was retrieved from the table.
>
>// create all subdirs and files
>local(temp_image = #imagedata -> ascopy)
>#extrapath = 'h67/'
>#this_dir = dir(#filepath + #extrapath)
>if(!#this_dir -> exists) => {
>#this_dir -> create
>}
>#temp_image -> scale(-height = 67, -thumbnail)
>#temp_image -> save(#filepath + #extrapath + #filename)
>stdoutnl('image scaled to 67 ' + #filename)
>
>#extrapath = 'h133/'
>#this_dir = dir(#filepath + #extrapath)
>if(!#this_dir -> exists) => {
>#this_dir -> create
>}
>#temp_image = #imagedata -> ascopy
>#temp_image -> scale(-height = 133, -thumbnail)
>#temp_image -> save(#filepath + #extrapath + #filename)
>stdoutnl('image scaled to 133 ' + #filename)

How big are the original images?  That can cause memory usage
problems for very big JPEGs.  See:
http://www.imagemagick.org/Usage/formats/#jpg_read

But then I think you would have to use IM via sys_process to get
that -define parameter in there, or maybe the image tags have
been enhanced in 9.

I think this is a question for Kyle.

--steve


>-------
>Continues the same way for all the other sizes.
>When Lasso runs into trouble I get a couple of the log entries. Like:
>image scaled to 67 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
>image scaled to 133 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
>image scaled to 200 Fd0959274-e1b1-48c8-ac7e-200cac364c45.jpg
>image scaled to 67 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
>image scaled to 67 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
>image scaled to 133 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
>image scaled to 67 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg
>image scaled to 133 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
>image scaled to 200 Fa3f07d24-92dc-481d-8ad7-9f065e011eb1.jpg
>image scaled to 133 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg
>image scaled to 200 F3cc624eb-08b5-4188-a9f3-b3688bd710ab.jpg
>image scaled to 200 F6147290c-e01c-485f-8301-d2ba15e97cb3.jpg
>
>After that the instance restarts.
>
>HDB
>Jolle
>#############################################################
>This message is sent to you because you are subscribed to
>the mailing list Lasso
>[hidden email]
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
Done some more testing around this. I now have a test case that when run completely puts Lasso to a halt. Test done on Centos 5.8 using latest Lasso 9 distro.

Here's the test code:
<?LassoScript
debug->activate

local(testname = web_request -> param('name'))

local(sql = "SELECT file_data FROM demofile WHERE id = 'F92200da6-3963-48b1-ad7c-47a3f7ba9800' LIMIT 0,1")

inline(-database = 'demodb',
                -sql = #sql,
                -maxrecords = 1) => {
        if(error_code) => {
                log_critical('Error when getting file data: ' + error_msg)
        else(found_count > 0)

                local(imagedata = image(field('file_data')))
                local(filename = knop_unique9 + '.jpg')
                local(counter = 1)
                local(extrapath, temp_image)


                local(serve_path = '/_test/jolletests/' + knop_unique9 + '/')


                if(not dir(#serve_path) -> exists) => {
                        dir(#serve_path) -> create
                }

                debug -> timer(5, 'image handling') => {
log_critical('will save original imagesize ' + #counter + #testname)
                        #imagedata -> save(#serve_path + #counter + #filename)

                        // create all subfiles
stdoutnl('copy image var 67 ' + #counter + #testname)
                        #temp_image = #imagedata -> ascopy
                        #extrapath = 'h67' + #counter
stdoutnl('scale image 67 ' + #counter + #testname)
                        #temp_image -> scale(-height = 67, -thumbnail)
stdoutnl('save image 67 ' + #counter + #testname)
                        #temp_image -> save(#serve_path + #extrapath + #filename)

stdoutnl('copy image var 266 ' + #counter + #testname)
                        #temp_image = #imagedata -> ascopy
                        #extrapath = 'h266' + #counter
stdoutnl('scale image 266 ' + #counter + #testname)
                        #temp_image -> scale(-height = 67, -thumbnail)
stdoutnl('save image 266 ' + #counter + #testname)
                        #temp_image -> save(#serve_path + #extrapath + #filename)

stdoutnl('copy image var 640 ' + #counter + #testname)
                        #temp_image = #imagedata -> ascopy
                        #extrapath = 'h640' + #counter
stdoutnl('scale image 640 ' + #counter + #testname)
                        #temp_image -> scale(-height = 67)
stdoutnl('save image 640 ' + #counter + #testname)
                        #temp_image -> save(#serve_path + #extrapath + #filename)

                        #temp_image = null

                        #counter += 1

                }

                #imagedata = null

        }
}
stdoutnl('done image process test ' + #testname)


?>



When calling this from 5 different browser windows Lasso dies. As in not giving any response and not restarting the instance automatically.
Calls looked like:
http://testserver.tld/imageget.lasso?name=test5 // (1-5) used from different browser windows

Here are the last 20 rows in Lassos log (of 46 for this test):
save image 640 1test3
[2013-02-08 18:17:37] will save original imagesize 2test3
copy image var 67 2test3
scale image 266 1test4
save image 266 1test4
copy image var 640 1test4
scale image 67 2test3
save image 67 2test3
copy image var 266 2test3
scale image 67 2test2
save image 67 2test2
copy image var 266 2test2
scale image 640 1test4
save image 640 1test4
[2013-02-08 18:17:47] will save original imagesize 2test4
scale image 266 2test3
scale image 266 2test2
save image 266 2test3
save image 266 2test2
copy image var 67 2test4

After this Lasso stops responding. Trying to access other pages from the same instance results in nothing. No error message, no ISE, just a waiting browser. After waiting for about 10 minutes I restarted the instance from Instance manager.

Checking what processes the server runs I get a tremendous list of Lasso related processes. For example 141 occurrences of this:
root     28964  0.0  0.0   8716   944 ?        Ss   Feb04   0:00 /bin/sh -c /var/lasso/cli/log_http_process >/dev/null 2>&1
root     28965  0.0  0.2 291880 20836 ?        Sl   Feb04   0:01 /usr/bin/lasso9 /var/lasso/cli/log_http_process


The other Lasso processes are these:
root     10547  0.0  0.4 398540 35584 ?        Ssl  Jan31 .  4:40 /usr/sbin/lassoimd
_lasso   10552  0.0  0.7 604844 66172 ?        Sl   Jan31   0:20 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
_lasso   10558  0.0  0.7 563864 66060 ?        Sl   Jan31   0:22 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
root     11379  0.0  0.0 132028  2568 pts/0    S+   Jan28   0:01 sudo tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
root     11381  0.0  0.0  58932   612 pts/0    S+   Jan28   0:01 tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
root     19092  0.0  0.0  63260   828 pts/1    R+   18:29   0:00 grep lasso
root     22417  0.0  0.0 131136  2572 pts/2    S+   Feb05   0:00 sudo tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
root     22419  0.0  0.0  61392   848 pts/2    S+   Feb05   0:00 tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
_lasso   28157  1.9 21.4 3194464 1803276 ?     Rl   Feb07  45:01 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
_lasso   28168  0.0  0.0      0     0 ?        Z    Feb07   0:00 [hostname] <defunct>


After the restart of the instance the long list of Lasso processes is still there.

Anyone with any clues?

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
A detail that can be relevant, The test file used is about 2.8 MB large.

Some more explanation on why this matters. We uses similar code as in the test case in at least two different situations.

1/ The users upload images/photos and they need to be scaled to different sizes so that they can later be served for different purposes; thumbnails, small or large versions or even the original image.

2/ Users request images to be viewed in a browser or downloaded. These images can be existing on the servers disk already. If they are they're just served using file_serve. But it could also be that the images only reside inside the file table. For example if the upload was made on a different server. In this case the image is first scaled and saved to disk before being served.

These images are usually restricted in different ways so we can't have them just as regular apache calls. They have to be evaluated by Lasso first to see if the user has a right to access them.

The need to deal with these calls can be of high frequency. We have situations where there can be thousands of for example students that has to upload photos of themselves to be used as ID photos. In a fairly short time frame.
To have Lasso grind to a complete stop when called from five different browsers at about the same time is... not ideal...

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Bil Corry-3
In reply to this post by Jolle Carlestam-3
A guy goes to the doctor and says, "Doc, my arm hurts when I raise it like this,". Doctor replies, "Then don't do that."

Sounds like the ImageMagick library isn't thread-safe.

Can you use the thread tags to create a thread-safe version of the IM tags?

- Bil

On Feb 8, 2013, at 9:57 AM, Jolle Carlestam <[hidden email]> wrote:

> Done some more testing around this. I now have a test case that when run completely puts Lasso to a halt. Test done on Centos 5.8 using latest Lasso 9 distro.
>
> Here's the test code:
> <?LassoScript
> debug->activate
>
> local(testname = web_request -> param('name'))
>
> local(sql = "SELECT file_data FROM demofile WHERE id = 'F92200da6-3963-48b1-ad7c-47a3f7ba9800' LIMIT 0,1")
>
> inline(-database = 'demodb',
>        -sql = #sql,
>        -maxrecords = 1) => {
>    if(error_code) => {
>        log_critical('Error when getting file data: ' + error_msg)
>    else(found_count > 0)
>
>        local(imagedata = image(field('file_data')))
>        local(filename = knop_unique9 + '.jpg')
>        local(counter = 1)
>        local(extrapath, temp_image)
>
>
>        local(serve_path = '/_test/jolletests/' + knop_unique9 + '/')
>
>
>        if(not dir(#serve_path) -> exists) => {
>            dir(#serve_path) -> create
>        }
>
>        debug -> timer(5, 'image handling') => {
> log_critical('will save original imagesize ' + #counter + #testname)
>            #imagedata -> save(#serve_path + #counter + #filename)
>
>            // create all subfiles
> stdoutnl('copy image var 67 ' + #counter + #testname)
>            #temp_image = #imagedata -> ascopy
>            #extrapath = 'h67' + #counter
> stdoutnl('scale image 67 ' + #counter + #testname)
>            #temp_image -> scale(-height = 67, -thumbnail)
> stdoutnl('save image 67 ' + #counter + #testname)
>            #temp_image -> save(#serve_path + #extrapath + #filename)
>
> stdoutnl('copy image var 266 ' + #counter + #testname)
>            #temp_image = #imagedata -> ascopy
>            #extrapath = 'h266' + #counter
> stdoutnl('scale image 266 ' + #counter + #testname)
>            #temp_image -> scale(-height = 67, -thumbnail)
> stdoutnl('save image 266 ' + #counter + #testname)
>            #temp_image -> save(#serve_path + #extrapath + #filename)
>
> stdoutnl('copy image var 640 ' + #counter + #testname)
>            #temp_image = #imagedata -> ascopy
>            #extrapath = 'h640' + #counter
> stdoutnl('scale image 640 ' + #counter + #testname)
>            #temp_image -> scale(-height = 67)
> stdoutnl('save image 640 ' + #counter + #testname)
>            #temp_image -> save(#serve_path + #extrapath + #filename)
>
>            #temp_image = null
>
>            #counter += 1
>
>        }
>
>        #imagedata = null
>
>    }
> }
> stdoutnl('done image process test ' + #testname)
>
>
> ?>
>
>
>
> When calling this from 5 different browser windows Lasso dies. As in not giving any response and not restarting the instance automatically.
> Calls looked like:
> http://testserver.tld/imageget.lasso?name=test5 // (1-5) used from different browser windows
>
> Here are the last 20 rows in Lassos log (of 46 for this test):
> save image 640 1test3
> [2013-02-08 18:17:37] will save original imagesize 2test3
> copy image var 67 2test3
> scale image 266 1test4
> save image 266 1test4
> copy image var 640 1test4
> scale image 67 2test3
> save image 67 2test3
> copy image var 266 2test3
> scale image 67 2test2
> save image 67 2test2
> copy image var 266 2test2
> scale image 640 1test4
> save image 640 1test4
> [2013-02-08 18:17:47] will save original imagesize 2test4
> scale image 266 2test3
> scale image 266 2test2
> save image 266 2test3
> save image 266 2test2
> copy image var 67 2test4
>
> After this Lasso stops responding. Trying to access other pages from the same instance results in nothing. No error message, no ISE, just a waiting browser. After waiting for about 10 minutes I restarted the instance from Instance manager.
>
> Checking what processes the server runs I get a tremendous list of Lasso related processes. For example 141 occurrences of this:
> root     28964  0.0  0.0   8716   944 ?        Ss   Feb04   0:00 /bin/sh -c /var/lasso/cli/log_http_process >/dev/null 2>&1
> root     28965  0.0  0.2 291880 20836 ?        Sl   Feb04   0:01 /usr/bin/lasso9 /var/lasso/cli/log_http_process
>
>
> The other Lasso processes are these:
> root     10547  0.0  0.4 398540 35584 ?        Ssl  Jan31 .  4:40 /usr/sbin/lassoimd
> _lasso   10552  0.0  0.7 604844 66172 ?        Sl   Jan31   0:20 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
> _lasso   10558  0.0  0.7 563864 66060 ?        Sl   Jan31   0:22 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
> root     11379  0.0  0.0 132028  2568 pts/0    S+   Jan28   0:01 sudo tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
> root     11381  0.0  0.0  58932   612 pts/0    S+   Jan28   0:01 tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
> root     19092  0.0  0.0  63260   828 pts/1    R+   18:29   0:00 grep lasso
> root     22417  0.0  0.0 131136  2572 pts/2    S+   Feb05   0:00 sudo tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
> root     22419  0.0  0.0  61392   848 pts/2    S+   Feb05   0:00 tail -F -n 50 /var/lasso/instances/amtac_standard/lasso.out.txt
> _lasso   28157  1.9 21.4 3194464 1803276 ?     Rl   Feb07  45:01 /usr/sbin/lassoserver -flisten lasso.fastcgi.sock
> _lasso   28168  0.0  0.0      0     0 ?        Z    Feb07   0:00 [hostname] <defunct>
>
>
> After the restart of the instance the long list of Lasso processes is still there.
>
> Anyone with any clues?
>
> HDB
> Jolle
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list Lasso
> [hidden email]
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
8 feb 2013 kl. 10:20 skrev Bil Corry <[hidden email]>:

Hello Bil!

> A guy goes to the doctor and says, "Doc, my arm hurts when I raise it like this,". Doctor replies, "Then don't do that."

I thought that was Steve Jobs reply during Antennagate...

> Sounds like the ImageMagick library isn't thread-safe.
>
> Can you use the thread tags to create a thread-safe version of the IM tags?

Been thinking that it could be the best solution. Was just hoping someone would give some code pointers on how to best accomplish it.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
In reply to this post by Bil Corry-3
8 feb 2013 kl. 10:20 skrev Bil Corry <[hidden email]>:

> Sounds like the ImageMagick library isn't thread-safe.
>
> Can you use the thread tags to create a thread-safe version of the IM tags?

Revisiting this issue. And unfortunately it is becoming a really serious problem for us. Servers are crashing left, right and in the middle.

I tried the thread route and it seems that it solved nothing. Even when making sure that the image scaling and saving calls are done one at a time, thru the use of a thread object, Lasso still crashes.

My present guess is that ImageMagick / Java doesn't clear out memory fast enough and that repeated calls close after one another maxes out the allocated memory.
Is there someway I can allocate more memory to ImageMagick / JVM?
And / or is there someway I can empty the allocated memory before or after a call?

Here's a part of the test code used.

First the thread object:

define amtac_atomic_thread => thread {
        public run(code::capture, verbose::any = false) => {
                // conserve error
                error_push
                handle => { error_pop }

                protect => {
                        handle_failure => {
                                log_critical('Error when executing an amtac_atomic call ' + error_msg)
                                #verbose ? return error_msg
                        }
                        return #code -> invoke
                }
        }
}

define amtac_atomic(code::capture, -verbose::boolean = false) => amtac_atomic_thread -> run(#code, #verbose)


Then the test calls:
<?LassoScript
debug->activate

local(testname = web_request -> param('name'))

local(sql = "SELECT file_data FROM testtable WHERE id = 'Fb9aa275f-ab25-4ddc-9f64-7c56aa974c87' LIMIT 0,1")

inline(-database = 'testdb',
                -table = 'testtable',
                -sql = #sql,
                -maxrecords = 1) => {
        if(error_code) => {
                log_critical('Error when getting file for download, creating file: ' + error_msg)
        else(found_count > 0)

                local(imagedata = image(field('file_data')))
                local(filename = knop_unique9 + '.jpg')
                local(counter = 1)
                local(extrapath, temp_image)

                local(serve_path = '/_tmp/jolletests/' + knop_unique9 + '/')

                if(not dir(#serve_path) -> exists) => {
                        dir(#serve_path) -> create
                }
                local(full_serve_path = file(#serve_path) -> fullPath)

                debug -> timer(5, 'image handling') => {^
                        // create all subfiles
                        amtac_atomic({
                                #extrapath = 'h67' + #counter + '_'
                                #imagedata -> scale(-height = 67, -thumbnail)
                                #imagedata -> save(#full_serve_path + #extrapath + #filename)
                        }, -verbose)
                        amtac_atomic({
                                #extrapath = 'h266' + #counter + '_'
                                #imagedata -> scale(-height = 266, -thumbnail)
                                #imagedata -> save(#full_serve_path + #extrapath + #filename)
                        }, -verbose)
                        amtac_atomic({
                                #extrapath = 'h640' + #counter + '_'
                                #imagedata -> scale(-height = 640, -thumbnail)
                                #imagedata -> save(#full_serve_path + #extrapath + #filename)
                        }, -verbose)

                        #counter += 1
                ^}

                #imagedata = null

        }
}
stdoutnl('done image process test ' + #testname)


?>
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
18 feb 2013 kl. 07:40 skrev Jolle Carlestam <[hidden email]>:

> local(full_serve_path = file(#serve_path) -> fullPath)

Hm, right. If someone tries to test the code, this needs an add-on to the file type.
define file -> fullPath::string => .realPath(.path)

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

stevepiercy
In reply to this post by Jolle Carlestam-3
AFAIK, IM and JVM have nothing in common.  If the JVM is
gobbling up RAM, then it's from some other function that does
use it, e.g., PDF, net.

Nevertheless, to set the JVM memory values, below is what I did
in 8.x, but I don't know whether it is possible to change in 9
and the values I used may need adjusting for modern systems with
higher memory availability.  Details:
https://forums.oracle.com/forums/message.jspa?messageID=3813540#3813540

Your code indicates you did not try executing IM via
sys_process.  If you punt the functions to IM directly, then
perhaps Lasso memory use won't creep upward.  It's worth a
shot.  :/

--steve

========================

Change the JVM settings for the Lasso site:

SiteAdmin > Utility > SQL > Browser

add new entry:
insert into global_prefs (`store_key`,`data`) values
("java_vm_options","-Xms8m -Xmx16m");

or update existing:
update global_prefs set `data` = "-Xms8m -Xmx16m" where
`store_key` = "java_vm_options";

Then restart the site.

========================

On 2/18/13 at 6:40 AM, [hidden email] (Jolle
Carlestam) pronounced:

>8 feb 2013 kl. 10:20 skrev Bil Corry <[hidden email]>:
>
>>Sounds like the ImageMagick library isn't thread-safe.
>>
>>Can you use the thread tags to create a thread-safe version of the IM tags?
>
>Revisiting this issue. And unfortunately it is becoming a
>really serious problem for us. Servers are crashing left, right
>and in the middle.
>
>I tried the thread route and it seems that it solved nothing.
>Even when making sure that the image scaling and saving calls
>are done one at a time, thru the use of a thread object, Lasso
>still crashes.
>
>My present guess is that ImageMagick / Java doesn't clear out
>memory fast enough and that repeated calls close after one
>another maxes out the allocated memory.
>Is there someway I can allocate more memory to ImageMagick / JVM?
>And / or is there someway I can empty the allocated memory before or after a call?
>
>Here's a part of the test code used.
>
>First the thread object:
>
>define amtac_atomic_thread => thread {
>public run(code::capture, verbose::any = false) => {
>// conserve error
>error_push
>handle => { error_pop }
>
>protect => {
>handle_failure => {
>log_critical('Error when executing an amtac_atomic call ' + error_msg)
>#verbose ? return error_msg
>}
>return #code -> invoke
>}
>}
>}
>
>define amtac_atomic(code::capture, -verbose::boolean = false)
>=> amtac_atomic_thread -> run(#code, #verbose)
>
>
>Then the test calls:
><?LassoScript
>debug->activate
>
>local(testname = web_request -> param('name'))
>
>local(sql = "SELECT file_data FROM testtable WHERE id =
>'Fb9aa275f-ab25-4ddc-9f64-7c56aa974c87' LIMIT 0,1")
>
>inline(-database = 'testdb',
>-table = 'testtable',
>-sql = #sql,
>-maxrecords = 1) => {
>if(error_code) => {
>log_critical('Error when getting file for download, creating
>file: ' + error_msg)
>else(found_count > 0)
>
>local(imagedata = image(field('file_data')))
>local(filename = knop_unique9 + '.jpg')
>local(counter = 1)
>local(extrapath, temp_image)
>
>local(serve_path = '/_tmp/jolletests/' + knop_unique9 + '/')
>
>if(not dir(#serve_path) -> exists) => {
>dir(#serve_path) -> create
>}
>local(full_serve_path = file(#serve_path) -> fullPath)
>
>debug -> timer(5, 'image handling') => {^
>// create all subfiles
>amtac_atomic({
>#extrapath = 'h67' + #counter + '_'
>#imagedata -> scale(-height = 67, -thumbnail)
>#imagedata -> save(#full_serve_path + #extrapath + #filename)
>}, -verbose)
>amtac_atomic({
>#extrapath = 'h266' + #counter + '_'
>#imagedata -> scale(-height = 266, -thumbnail)
>#imagedata -> save(#full_serve_path + #extrapath + #filename)
>}, -verbose)
>amtac_atomic({
>#extrapath = 'h640' + #counter + '_'
>#imagedata -> scale(-height = 640, -thumbnail)
>#imagedata -> save(#full_serve_path + #extrapath + #filename)
>}, -verbose)
>
>#counter += 1
>^}
>
>#imagedata = null
>
>}
>}
>stdoutnl('done image process test ' + #testname)
>
>
>?>
>#############################################################
>This message is sent to you because you are subscribed to
>the mailing list Lasso
>[hidden email]
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
18 feb 2013 kl. 09:12 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> Your code indicates you did not try executing IM via sys_process.  If you punt the functions to IM directly, then perhaps Lasso memory use won't creep upward.  It's worth a shot.  :/

I've found no evidence that Lassos memory creep up. It seems to be all on the process Lasso relies on. I thought that IM was called using the JVM but I admit that was just an assumption from my part. I will do a test using sysprocess and see if that helps.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
18 feb 2013 kl. 09:32 skrev Jolle Carlestam <[hidden email]>:

> 18 feb 2013 kl. 09:12 skrev Steve Piercy - Web Site Builder <[hidden email]>:
>
>> Your code indicates you did not try executing IM via sys_process.  If you punt the functions to IM directly, then perhaps Lasso memory use won't creep upward.  It's worth a shot.  :/
>
> I've found no evidence that Lassos memory creep up. It seems to be all on the process Lasso relies on. I thought that IM was called using the JVM but I admit that was just an assumption from my part. I will do a test using sysprocess and see if that helps.

I've now done some tests using sys_process. It looked as if this would be more reliable but even when called using a thread object it crashed lasso.
Here's an example snippet:
amtac_atomic({
        #extrapath = 'h67' + #counter + '_'
        local(mysys) = sys_process('/usr/bin/convert', (:#full_serve_path + #filename, '-thumbnail', '67x67', #full_serve_path + #extrapath + #filename))
        #mysys -> wait
        local(out = #mysys -> readString)
        #out -> size == 0 ? #out = #mysys -> readerror
        #mysys -> close
        return #out
}, -verbose)

But, isolating possible issues I found that it was possible to kill Lasso just by calling save on an image object. This code alone in enough to force the instance to restart when called repeatedly:

local(imagedata = image(field('file_data')))

debug -> timer(50, 'saving img data') => {^
        amtac_atomic({
                #imagedata -> save(#full_serve_path + #counter + '_' + #filename)
                #imagedata = null
                #counter += 1
        }, -verbose)
^}

Note that this is still code running in a thread and thus only called one at a time.

My next attempt will be to save the file data without creating an image object of it first. We'll see what that can bring.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Wade Maxfield
In reply to this post by stevepiercy
On 18/02/2013, at 9:12 PM, Steve Piercy - Web Site Builder <[hidden email]> wrote:

> Your code indicates you did not try executing IM via sys_process.  If you punt the functions to IM directly, then perhaps Lasso memory use won't creep upward.  It's worth a shot.  :/

That's the path I went on 8.x to avoid Lasso being killed for excessive memory usage. So I'd definitely give it a try if possible.

 - Wade


#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
In reply to this post by Jolle Carlestam-3
18 feb 2013 kl. 11:48 skrev Jolle Carlestam <[hidden email]>:

>
> But, isolating possible issues I found that it was possible to kill Lasso just by calling save on an image object. This code alone in enough to force the instance to restart when called repeatedly:
>
> local(imagedata = image(field('file_data')))
>
> debug -> timer(50, 'saving img data') => {^
> amtac_atomic({
> #imagedata -> save(#full_serve_path + #counter + '_' + #filename)
> #imagedata = null
> #counter += 1
> }, -verbose)
> ^}
>
> Note that this is still code running in a thread and thus only called one at a time.
>
> My next attempt will be to save the file data without creating an image object of it first. We'll see what that can bring.

Well, I will do some more testing. But it does indeed look like I can bypass the problem by not using Lasso image type at all.

By replacing the above code with a pure file save and then using sys_process to manipulate the image file I've managed to keep Lasso going despite considerable pressure. I had each image file resized three times in each round and repeating that 50 times. Then calling the same URL from 5 different browser instances. In total having the resize and save code executed some 750 times. It took a while to process but it did not fail.
And note that this time I did not protect the code by executing it within a thread object. Earlier tests failed long before getting these numbers. Actually could not get past this line when stressed: #imagedata -> save(#full_serve_path + #counter + '_' + #filename)


Here's the test:

<?LassoScript
debug->activate

local(testname = web_request -> param('name'))

local(sql = "SELECT file_data FROM testtable WHERE id = 'Fb9aa275f-ab25-4ddc-9f64-7c56aa974c87' LIMIT 0,1")

inline(-database = 'testdb',
                -sql = #sql,
                -maxrecords = 1) => {
        if(error_code) => {^
                log_critical('Error when getting file for download, creating file: ' + error_msg)
        else(found_count > 0)

                local(filename = #testname + '.jpg')
                local(counter = 1)
                local(extrapath, temp_image)


                local(serve_path = '/_test/jolletests/' + #testname + '/')


                if(not dir(#serve_path) -> exists) => {
                        dir(#serve_path) -> create
                }
                local(full_serve_path = file(#serve_path) -> fullPath)

                debug -> timer(50, 'saving file data') => {^
                        local(imagedataraw = field('file_data'))
                        local(imgfile = file(#serve_path + #counter + '_' #filename))

                        #imgfile -> openWriteOnly
                        #imgfile -> doWithClose => {
                                #imgfile -> writeBytes(#imagedataraw)
                        }
                        #extrapath = 'h67' + #counter + '_'
                        local(mysys) = sys_process('/usr/bin/convert', (:#full_serve_path + #counter + '_' #filename, '-thumbnail', '67x67', #full_serve_path + #extrapath + #counter + '_' + #filename))
                        #mysys -> wait
                        local(out = #mysys -> readString)
                        #out -> size == 0 ? #out = #mysys -> readerror
                        #mysys -> close
                        #out

                        #extrapath = 'h266' + #counter + '_'
                        local(mysys) = sys_process('/usr/bin/convert', (:#full_serve_path + #counter + '_' #filename, '-thumbnail', '266x266', #full_serve_path + #extrapath + #counter + '_' + #filename))
                        #mysys -> wait
                        local(out = #mysys -> readString)
                        #out -> size == 0 ? #out = #mysys -> readerror
                        #mysys -> close
                        #out

                        #extrapath = 'h640' + #counter + '_'
                        local(mysys) = sys_process('/usr/bin/convert', (:#full_serve_path + #counter + '_' #filename, '-thumbnail', '640x640', #full_serve_path + #extrapath + #counter + '_' + #filename))
                        #mysys -> wait
                        local(out = #mysys -> readString)
                        #out -> size == 0 ? #out = #mysys -> readerror
                        #mysys -> close
                        #out

                        #counter += 1

                ^}
        ^}
}
stdoutnl('done image process test ' + #testname)


?>

So, time for some lunch.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

stevepiercy
Were you originally loading file data into Lasso's image type,
then saving it?

And now you load file data into a Lasso file type, then save it?

If so, then that indicates something is amiss in the image->save method.

Also to improve speed, I suggest resizing the original image to
the largest thumbnail size first, then use the resulting
thumbnail to resize to the next smaller size, and repeat.  Thus
you read in successively smaller image files to lower the
resource consumption, instead of reading in the big fattie three times.

Note that -thumbnail "uses '-sample' to shrink the image down to
5 times the final height", so if you follow the suggested speed
improvement, the successively smaller images may be of lower
quality than desired.  Test to confirm.
http://www.imagemagick.org/Usage/resize/#thumbnail

Finally instead of -thumbnail, you could apply the three
commands in succession with specific options to fine tune the process.

--steve


On 2/18/13 at 11:29 AM, [hidden email] (Jolle
Carlestam) pronounced:

>18 feb 2013 kl. 11:48 skrev Jolle Carlestam <[hidden email]>:
>>
>>But, isolating possible issues I found that it was possible to kill Lasso just
>by calling save on an image object. This code alone in enough
>to force the instance to restart when called repeatedly:
>>
>>local(imagedata = image(field('file_data')))
>>
>>debug -> timer(50, 'saving img data') => {^
>>amtac_atomic({
>>#imagedata -> save(#full_serve_path + #counter + '_' + #filename)
>>#imagedata = null
>>#counter += 1
>>}, -verbose)
>>^}
>>
>>Note that this is still code running in a thread and thus only called one at a
>time.
>>
>>My next attempt will be to save the file data without creating an image object
>of it first. We'll see what that can bring.
>
>Well, I will do some more testing. But it does indeed look like
>I can bypass the problem by not using Lasso image type at all.
>
>By replacing the above code with a pure file save and then
>using sys_process to manipulate the image file I've managed to
>keep Lasso going despite considerable pressure. I had each
>image file resized three times in each round and repeating that
>50 times. Then calling the same URL from 5 different browser
>instances. In total having the resize and save code executed
>some 750 times. It took a while to process but it did not fail.
>And note that this time I did not protect the code by executing
>it within a thread object. Earlier tests failed long before
>getting these numbers. Actually could not get past this line
>when stressed: #imagedata -> save(#full_serve_path + #counter +
>'_' + #filename)
>
>
>Here's the test:
>
><?LassoScript
>debug->activate
>
>local(testname = web_request -> param('name'))
>
>local(sql = "SELECT file_data FROM testtable WHERE id =
>'Fb9aa275f-ab25-4ddc-9f64-7c56aa974c87' LIMIT 0,1")
>
>inline(-database = 'testdb',
>-sql = #sql,
>-maxrecords = 1) => {
>if(error_code) => {^
>log_critical('Error when getting file for download, creating
>file: ' + error_msg)
>else(found_count > 0)
>
>local(filename = #testname + '.jpg')
>local(counter = 1)
>local(extrapath, temp_image)
>
>
>local(serve_path = '/_test/jolletests/' + #testname + '/')
>
>
>if(not dir(#serve_path) -> exists) => {
>dir(#serve_path) -> create
>}
>local(full_serve_path = file(#serve_path) -> fullPath)
>
>debug -> timer(50, 'saving file data') => {^
>local(imagedataraw = field('file_data'))
>local(imgfile = file(#serve_path + #counter + '_' #filename))
>
>#imgfile -> openWriteOnly
>#imgfile -> doWithClose => {
>#imgfile -> writeBytes(#imagedataraw)
>}
>#extrapath = 'h67' + #counter + '_'
>local(mysys) = sys_process('/usr/bin/convert',
>(:#full_serve_path + #counter + '_' #filename, '-thumbnail',
>'67x67', #full_serve_path + #extrapath + #counter + '_' + #filename))
>#mysys -> wait
>local(out = #mysys -> readString)
>#out -> size == 0 ? #out = #mysys -> readerror
>#mysys -> close
>#out
>
>#extrapath = 'h266' + #counter + '_'
>local(mysys) = sys_process('/usr/bin/convert',
>(:#full_serve_path + #counter + '_' #filename, '-thumbnail',
>'266x266', #full_serve_path + #extrapath + #counter + '_' + #filename))
>#mysys -> wait
>local(out = #mysys -> readString)
>#out -> size == 0 ? #out = #mysys -> readerror
>#mysys -> close
>#out
>
>#extrapath = 'h640' + #counter + '_'
>local(mysys) = sys_process('/usr/bin/convert',
>(:#full_serve_path + #counter + '_' #filename, '-thumbnail',
>'640x640', #full_serve_path + #extrapath + #counter + '_' + #filename))
>#mysys -> wait
>local(out = #mysys -> readString)
>#out -> size == 0 ? #out = #mysys -> readerror
>#mysys -> close
>#out
>
>#counter += 1
>
>^}
>^}
>}
>stdoutnl('done image process test ' + #testname)
>
>
>?>
>
>So, time for some lunch.
>
>HDB
>Jolle
>#############################################################
>This message is sent to you because you are subscribed to
>the mailing list Lasso
>[hidden email]
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Steve Piercy               Web Site Builder              
Soquel, CA
<[hidden email]>                  <http://www.StevePiercy.com/>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
18 feb 2013 kl. 20:01 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> Were you originally loading file data into Lasso's image type, then saving it?
>
> And now you load file data into a Lasso file type, then save it?
>
Yes, data coming from a Mysql table blob field.

> If so, then that indicates something is amiss in the image->save method.

I fully agree.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Calling imageMagick in parallel crashes Lasso 9

Jolle Carlestam-3
In reply to this post by stevepiercy
18 feb 2013 kl. 20:01 skrev Steve Piercy - Web Site Builder <[hidden email]>:

> Also to improve speed, I suggest resizing the original image to the largest thumbnail size first, then use the resulting thumbnail to resize to the next smaller size, and repeat.  Thus you read in successively smaller image files to lower the resource consumption, instead of reading in the big fattie three times.

We did a lot of testing earlier on differences in scaling and the resulting quality. This way did reduce quality significantly for the smaller images.
Our new approach is to not do more versions than is needed for the immediate call. If we at a later stage want an image with a different resolution we do the scaling for that size at that point in time. This reduces he overall load of the servers.

HDB
Jolle
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Lasso 8.6 on CentOS

Roy William Gabrielsen
In reply to this post by stevepiercy
Dear list,

Is there a better guide some place for installing Lasso 8.6 og latest CentOS 6.4 x86_64 ?
http://www.lassosoft.com/Lasso-Professional-86-Download

Need it more step by step..

Thanx!

Roy Gabrielsen

#############################################################

Attend the Lasso Developer Conference 2013!
Sept 12-14, 2013 in Niagara Falls, Canada
http://www.lassosoft.com/LDC-niagara-falls-2013

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Lasso 8.6 on CentOS

Brad Lindsay
On 5/19/13 10:09 AM, Roy William Gabrielsen wrote:
> Dear list,
>
> Is there a better guide some place for installing Lasso 8.6 og latest CentOS 6.4 x86_64 ?
> http://www.lassosoft.com/Lasso-Professional-86-Download
>

Below is the link to the step-by-step guide, but you'll notice that it's
for CentOS 5. Lasso 8.6 isn't currently supported on CentOS 6. 8.6 was
meant to be a sunset release and CentOS 6 wasn't around then. However,
recently there have been requests for Lasso 8.6 to run on CentOS 6 and
so that's been added to the Road Map that Certified Lasso Developers
vote on.


Step By Step Instructions for CentOS 5:
http://www.lassosoft.com/Lasso-Professional-86-Download#CentOS

Sean Stevens about adding CentOS 6 support for 8.6:
http://www.lassosoft.com/lassotalk/msg/272044/Re+Nothing+LassoSoft+86+On+CentOS+6+anybody

Lasso Road Map:
http://www.lassosoft.com/Lasso-Roadmap


HTH,
Brad

#############################################################

Attend the Lasso Developer Conference 2013!
Sept 12-14, 2013 in Niagara Falls, Canada
http://www.lassosoft.com/LDC-niagara-falls-2013

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
12