seems like link if ok

bash-3.00# dladm  show-dev  bge0
bge0            link: up        speed: 100   Mbps       duplex: full


On Thu, May 22, 2008 at 9:14 PM, Robert Hodges <[EMAIL PROTECTED]>
wrote:

>  Hi Shai,
>
> This is a shot in the dark, but can you confirm that the Sun networking is
> working correctly?  I have had problems in the past with Solaris connecting
> to the network in half-duplex mode.  Here are a couple of commands that
> might help:
>
>
>    1. Use dmesg to scan for boot-time messages about networking, e.g.:
>     'dmesg | grep duplex'
>    2. Use ndd to check the link mode e.g., 'ndd –get /dev/hme link_mode'
>
>
> I noticed from recent posts on the net that the half/full duplex problem
> seems to exit even in Solaris 10 as well as of course earlier releases.
>
> We're working on commercial support for Solaris with uni/cluster.  If I
> think of more things as we go through certification I'll be sure to post
> them to this list.
>
> Thanks, Robert
>
>
>
> On 5/22/08 10:48 AM, "Shai Weinstein" <[EMAIL PROTECTED]> wrote:
>
> still no luck with the Solaris.. any ideas ?
>
> Thanks
>
> On Fri, May 16, 2008 at 10:19 AM, Shai Weinstein <[EMAIL PROTECTED]>
> wrote:
>
> Hi
> I even tried to load the recommended patches for solaris nad the problem
> still accurs
> its not only the long time that it takes to bring the backend up, but it
> totally hangs (and not reacting to new client connections at all -not
> refusing connection, just not responding)
> for JVM u mean this ?
> bash-3.00# /usr/jdk/j2sdk1.4.2_13/bin/java -version
> java version "1.4.2_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06)
> Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode)
>
>
> Thanks
>
>
> On Thu, May 15, 2008 at 12:00 PM, Emmanuel Cecchet <[EMAIL PROTECTED]>
> wrote:
>
> Hi Shai,
>
> Thanks a lot for this feedback. There is certainly a problem with the JVM
> for Solaris.
> My guess is that this probably comes from the network stack implementation
> and how TCP_NODELAY can be implemented on that platform (hence the longer
> recovery time).
> Could you try another JVM on Solaris to see if you notice any improvement?
> What is the exact vendor and version number of your Solaris JVM?
>
> Thanks for the feedback,
> Emmanuel
>
> Ok
> So I went and tried the same setup with a difference:
> original setup:
> 1 controller on solaris 10 (sparc), with 2 linux mysqld backends.
> now:
> 1 controller on linux with 2 linux mysqld backends
>
> I tested and I didn't have the problem of the controller hanging..
> and controller keeps getting connections while backing up/enabling a
> backend + enabling the backend doesnt take too long like with a solaris
> controller...
>
> it seems to hang right after a backup is finished and it try to re-enable
> backed up backend
>
> what could be the solaris problem ?
> (I use same java 1.4.2 for the controller and 1.5.0 for myositis on both
> OSs)
>
> Thanks
>
> On Tue, May 13, 2008 at 12:42 PM, Shai Weinstein <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>> wrote:
>
>     hello
>
>     On Tue, May 13, 2008 at 1:12 AM, Emmanuel Cecchet
>     <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED]>>
> wrote:
>
>         Hi Shai,
>
>
>             it was not disabled before the backup.. also no errors was
>             displayed during or after backup
>
>         Did you see a message saying that the backup was completed?
>         What was the backup state when you tried to enable it?
>
>
>     this from the log when i start the backup:
>     http://pastesite.com/794
>
>     the backend was automatically enabled but during this time (~3
>     minutes) the vdb was not accesible by any client (its not in
>     production so only 1 client..)
>
>     on Myosotis i set the persistent connections option to false
>     I don't know what else to try , maybe the mysql connector is not
>     ok ? i'm using the latest stable one from mysql.com 
> <http://mysql.com><http://mysql.com>
>     <http://mysql.com> <http://mysql.com> version 5.1.6
>
>     there are no any errors, only this warning:
>     12:26:46,970 WARN  DatabaseBackend.myDB.one Default connection
>     manager undefined in backend configuration, setting to a
>     VariablePoolConnectionManager
>
>
>             I dont think I use persistent connections - here is my
>             config (in a paste site):
>             http://paste.lisp.org/display/60634
>
>         The config looks good.
>         The persistent connection option is set on the driver side so
>         I can't tell from the virtual database config file.
>         I have not played with persistent connections for a long time,
>         so there might be a bug that induces the behavior you indicate
>         but this looks strange since we can log open/close persistent
>         connection events. So it should not block anything even while
>         enabling a new backend. Try to see if it changes anything when
>         persistent connection are enabled or disabled. You might need
>         help from the Myosotis mailing list if you don't find the
>         option there.
>         Note though that your connection pool size is only 50 per
>         backend so you can't have more than 50 client connections.
>         After 50 connections new clients will be blocking no matter
>         what is the state of your backends.
>
>
>                Which version of Sequoia are you using?
>
>
>             2.10.10
>
>         This is good.
>
>
>         Keep us posted with your progress,
>
>         Emmanuel
>
>         --         Emmanuel Cecchet
>         FTO @ Frog Thinker Open Source Development & Consulting
>         --
>         Web: http://www.frogthinker.org
>         email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED]>
>         Skype: emmanuel_cecchet
>
>
>
>
> --
> Robert Hodges, CTO, Continuent, Inc.
> Email:  [EMAIL PROTECTED]
> Mobile:  +1-510-501-3728  Skype:  hodgesrm
>
> _______________________________________________
> Sequoia mailing list
> [email protected]
> https://forge.continuent.org/mailman/listinfo/sequoia
>
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to