write-write conflict

I'm more suspicious of SOAP since SPSocket is/has been used in Hyper and we've not seen write-write conflicts coming from that direction (not completely ruled out) ... You are looking for class vars class instance vars ... the SPSocket instance might be shared between vms, but it shouldn't be ....

Dale
----- "Sean Allen" <[hidden email]> wrote:

| From that error,
|
| should we be doing the same with the 6 SpSocket class vars as well?
|
| On Fri, Apr 23, 2010 at 3:27 PM, Dale Henrichs
| <[hidden email]> wrote:
| > Sean,
| >
| > I'm under the weather today ... nasty little cold ... SOAP and
| commit conflicts would be something that is likely to be problem,
| since I haven't really tested it under concurrent loads ... the quick
| fix would be to find any state that is kept in class vars and store in
| the SessionTemps dictionary (there are a number of examples if you
| look for references) ... There should be no need to keep anything in a
| Gobal, other than for convenience...
| >
| > Dale
| > ----- "Sean Allen" <[hidden email]> wrote:
| >
| > | Hi Dale,
| > |
| > | Neither Hernan or I right now knows how to intepret this.
| > | Basically, I executed some code to issue a refund via Chase
| > | Paymentech
| > | which is run over Soap.
| > | The refund went through and I went in gemtools to commit and got
| a
| > | write-write conflict with the following info in the Write-Write:
| > |
| > | anArray( SpSocket, SoapHttpClient, #'CrLf'->'')
| > |
| > | Any ideas on that?
| >

Hernan,

Sorry for not getting back to you sooner, but I've been offline with a nasty cold ...

You _are_ getting conflicts in SPSocket, but I don't think that it is correct to share an instance of SPSocket, so the _real_ problem is finding out who is referencing the SPSocket a that is involved in the conflict

Looking at String referenced CrLF. Is only used as a class var in HTTPSocket and only set in HTTPSocket class>>initialize, so multiple gems are concurrently initializing HTTPSocket which is odd, but you should be able to track it down.

SoapHttpClient also has a class var call CrLF which is also only set during #initialize.

The SoapHttpClient conflict is probably caused by the fact that you must be sharing a SoapHttpClient instance between multiple gems ...

Just to be clear ... you could work around these conflicts by using SessionTemps, but you have to look closely at _why_ you are getting the conflicts and ask the question whether it is a good idea to persist the SoapHttpClient instance or not ... the instance itself should probably be in SessionTemps.

It looks like the SoapHttpClient holds onto an instance of a SPSocket as well, so 2 out of the 3 conflicts are very likely coming from the SoapHttpClient instance being shared...

Dale

----- "Hernan Wilkinson" <[hidden email]> wrote:

| Hi Dale,
|  correct me if I'm wrong but I understand that there are three objects
| with
| conflicts, those are: the class SPSocket, the class SoapHTTPClient and
| the
| association #'CrLf'->''.
|  If that is correct, why would you look only on the SoapHTTPClient? I
| mean,
| don't the three objects have a conflict?
|  Is there a way to get more info about the conflict? (what vars are
| the
| conflict ones, etc?)
|
|  Thanks,
|  Hernan.
| On Fri, Apr 23, 2010 at 5:41 PM, Dale Henrichs
| <[hidden email]>wrote:
|
| > I'm more suspicious of SOAP since SPSocket is/has been used in Hyper
| and
| > we've not seen write-write conflicts coming from that direction
| (not
| > completely ruled out) ... You are looking for class vars class
| instance vars
| > ... the SPSocket instance might be shared between vms, but it
| shouldn't be
| > ....
| >
| > Dale
| > ----- "Sean Allen" <[hidden email]> wrote:
| >
| > | From that error,
| > |
| > | should we be doing the same with the 6 SpSocket class vars as
| well?
| > |
| > | On Fri, Apr 23, 2010 at 3:27 PM, Dale Henrichs
| > | <[hidden email]> wrote:
| > | > Sean,
| > | >
| > | > I'm under the weather today ... nasty little cold ... SOAP and
| > | commit conflicts would be something that is likely to be problem,
| > | since I haven't really tested it under concurrent loads ... the
| quick
| > | fix would be to find any state that is kept in class vars and
| store in
| > | the SessionTemps dictionary (there are a number of examples if
| you
| > | look for references) ... There should be no need to keep anything
| in a
| > | Gobal, other than for convenience...
| > | >
| > | > Dale
| > | > ----- "Sean Allen" <[hidden email]> wrote:
| > | >
| > | > | Hi Dale,
| > | > |
| > | > | Neither Hernan or I right now knows how to intepret this.
| > | > | Basically, I executed some code to issue a refund via Chase
| > | > | Paymentech
| > | > | which is run over Soap.
| > | > | The refund went through and I went in gemtools to commit and
| got
| > | a
| > | > | write-write conflict with the following info in the
| Write-Write:
| > | > |
| > | > | anArray( SpSocket, SoapHttpClient, #'CrLf'->'')
| > | > |
| > | > | Any ideas on that?
| > | >
| >

The SpSocket conflict just might be related to the SoapHttpClient sharing .... unless you are still seeing the occasional SpSocket conflict...

Dale
----- "Hernan Wilkinson" <[hidden email]> wrote:

| Hi Dale,
|  no problem... I answer back later too! :-)
|  We found and issue on the SoapHttpClient code that cause the
| SoapHttpClient
| and CrLf association conflicts... but could not find why we got a
| conflict
| on the SPSocket... I'll let you know if we found something more.
| Thanks!
|
| On Thu, Apr 29, 2010 at 3:53 PM, Dale Henrichs
| <[hidden email]>wrote:
|
| > Hernan,
| >
| > Sorry for not getting back to you sooner, but I've been offline with
| a
| > nasty cold ...
| >
| > You _are_ getting conflicts in SPSocket, but I don't think that it
| is
| > correct to share an instance of SPSocket, so the _real_ problem is
| finding
| > out who is referencing the SPSocket a that is involved in the
| conflict
| >
| > Looking at String referenced CrLF. Is only used as a class var in
| > HTTPSocket and only set in HTTPSocket class>>initialize, so multiple
| gems
| > are concurrently initializing HTTPSocket which is odd, but you
| should be
| > able to track it down.
| >
| > SoapHttpClient also has a class var call CrLF which is also only set
| during
| > #initialize.
| >
| > The SoapHttpClient conflict is probably caused by the fact that you
| must be
| > sharing a SoapHttpClient instance between multiple gems ...
| >
| > Just to be clear ... you could work around these conflicts by using
| > SessionTemps, but you have to look closely at _why_ you are getting
| the
| > conflicts and ask the question whether it is a good idea to persist
| the
| > SoapHttpClient instance or not ... the instance itself should
| probably be in
| > SessionTemps.
| >
| > It looks like the SoapHttpClient holds onto an instance of a
| SPSocket as
| > well, so 2 out of the 3 conflicts are very likely coming from the
| > SoapHttpClient instance being shared...
| >
| > Dale
| >
| > ----- "Hernan Wilkinson" <[hidden email]> wrote:
| >
| > | Hi Dale,
| > |  correct me if I'm wrong but I understand that there are three
| objects
| > | with
| > | conflicts, those are: the class SPSocket, the class SoapHTTPClient
| and
| > | the
| > | association #'CrLf'->''.
| > |  If that is correct, why would you look only on the
| SoapHTTPClient? I
| > | mean,
| > | don't the three objects have a conflict?
| > |  Is there a way to get more info about the conflict? (what vars
| are
| > | the
| > | conflict ones, etc?)
| > |
| > |  Thanks,
| > |  Hernan.
| > | On Fri, Apr 23, 2010 at 5:41 PM, Dale Henrichs
| > | <[hidden email]>wrote:
| > |
| > | > I'm more suspicious of SOAP since SPSocket is/has been used in
| Hyper
| > | and
| > | > we've not seen write-write conflicts coming from that direction
| > | (not
| > | > completely ruled out) ... You are looking for class vars class
| > | instance vars
| > | > ... the SPSocket instance might be shared between vms, but it
| > | shouldn't be
| > | > ....
| > | >
| > | > Dale
| > | > ----- "Sean Allen" <[hidden email]> wrote:
| > | >
| > | > | From that error,
| > | > |
| > | > | should we be doing the same with the 6 SpSocket class vars as
| > | well?
| > | > |
| > | > | On Fri, Apr 23, 2010 at 3:27 PM, Dale Henrichs
| > | > | <[hidden email]> wrote:
| > | > | > Sean,
| > | > | >
| > | > | > I'm under the weather today ... nasty little cold ... SOAP
| and
| > | > | commit conflicts would be something that is likely to be
| problem,
| > | > | since I haven't really tested it under concurrent loads ...
| the
| > | quick
| > | > | fix would be to find any state that is kept in class vars and
| > | store in
| > | > | the SessionTemps dictionary (there are a number of examples
| if
| > | you
| > | > | look for references) ... There should be no need to keep
| anything
| > | in a
| > | > | Gobal, other than for convenience...
| > | > | >
| > | > | > Dale
| > | > | > ----- "Sean Allen" <[hidden email]> wrote:
| > | > | >
| > | > | > | Hi Dale,
| > | > | > |
| > | > | > | Neither Hernan or I right now knows how to intepret this.
| > | > | > | Basically, I executed some code to issue a refund via
| Chase
| > | > | > | Paymentech
| > | > | > | which is run over Soap.
| > | > | > | The refund went through and I went in gemtools to commit
| and
| > | got
| > | > | a
| > | > | > | write-write conflict with the following info in the
| > | Write-Write:
| > | > | > |
| > | > | > | anArray( SpSocket, SoapHttpClient, #'CrLf'->'')
| > | > | > |
| > | > | > | Any ideas on that?
| > | > | >
| > | >
| >

I thought that that the SoapHttpClient had a socket instance variable so if the SoapHttpClient was shared, the socket would be shared too and could lead to conflicts...

Dale
----- "Hernan Wilkinson" <[hidden email]> wrote:

| hmm.. I tought about that but there is no reference to a SPSocket from
| a
| class var or class instance var of SoapHttpSocket. Is there other
| reason you
| are thinking that could be generating the conflict?
|
| On Mon, May 3, 2010 at 2:19 PM, Dale Henrichs
| <[hidden email]>wrote:
|
| > The SpSocket conflict just might be related to the SoapHttpClient
| sharing
| > .... unless you are still seeing the occasional SpSocket
| conflict...
| >
| > Dale
| > ----- "Hernan Wilkinson" <[hidden email]> wrote:
| >
| > | Hi Dale,
| > |  no problem... I answer back later too! :-)
| > |  We found and issue on the SoapHttpClient code that cause the
| > | SoapHttpClient
| > | and CrLf association conflicts... but could not find why we got a
| > | conflict
| > | on the SPSocket... I'll let you know if we found something more.
| > | Thanks!
| > |
| > | On Thu, Apr 29, 2010 at 3:53 PM, Dale Henrichs
| > | <[hidden email]>wrote:
| > |
| > | > Hernan,
| > | >
| > | > Sorry for not getting back to you sooner, but I've been offline
| with
| > | a
| > | > nasty cold ...
| > | >
| > | > You _are_ getting conflicts in SPSocket, but I don't think that
| it
| > | is
| > | > correct to share an instance of SPSocket, so the _real_ problem
| is
| > | finding
| > | > out who is referencing the SPSocket a that is involved in the
| > | conflict
| > | >
| > | > Looking at String referenced CrLF. Is only used as a class var
| in
| > | > HTTPSocket and only set in HTTPSocket class>>initialize, so
| multiple
| > | gems
| > | > are concurrently initializing HTTPSocket which is odd, but you
| > | should be
| > | > able to track it down.
| > | >
| > | > SoapHttpClient also has a class var call CrLF which is also only
| set
| > | during
| > | > #initialize.
| > | >
| > | > The SoapHttpClient conflict is probably caused by the fact that
| you
| > | must be
| > | > sharing a SoapHttpClient instance between multiple gems ...
| > | >
| > | > Just to be clear ... you could work around these conflicts by
| using
| > | > SessionTemps, but you have to look closely at _why_ you are
| getting
| > | the
| > | > conflicts and ask the question whether it is a good idea to
| persist
| > | the
| > | > SoapHttpClient instance or not ... the instance itself should
| > | probably be in
| > | > SessionTemps.
| > | >
| > | > It looks like the SoapHttpClient holds onto an instance of a
| > | SPSocket as
| > | > well, so 2 out of the 3 conflicts are very likely coming from
| the
| > | > SoapHttpClient instance being shared...
| > | >
| > | > Dale
| > | >
| > | > ----- "Hernan Wilkinson" <[hidden email]> wrote:
| > | >
| > | > | Hi Dale,
| > | > |  correct me if I'm wrong but I understand that there are
| three
| > | objects
| > | > | with
| > | > | conflicts, those are: the class SPSocket, the class
| SoapHTTPClient
| > | and
| > | > | the
| > | > | association #'CrLf'->''.
| > | > |  If that is correct, why would you look only on the
| > | SoapHTTPClient? I
| > | > | mean,
| > | > | don't the three objects have a conflict?
| > | > |  Is there a way to get more info about the conflict? (what
| vars
| > | are
| > | > | the
| > | > | conflict ones, etc?)
| > | > |
| > | > |  Thanks,
| > | > |  Hernan.
| > | > | On Fri, Apr 23, 2010 at 5:41 PM, Dale Henrichs
| > | > | <[hidden email]>wrote:
| > | > |
| > | > | > I'm more suspicious of SOAP since SPSocket is/has been used
| in
| > | Hyper
| > | > | and
| > | > | > we've not seen write-write conflicts coming from that
| direction
| > | > | (not
| > | > | > completely ruled out) ... You are looking for class vars
| class
| > | > | instance vars
| > | > | > ... the SPSocket instance might be shared between vms, but
| it
| > | > | shouldn't be
| > | > | > ....
| > | > | >
| > | > | > Dale
| > | > | > ----- "Sean Allen" <[hidden email]> wrote:
| > | > | >
| > | > | > | From that error,
| > | > | > |
| > | > | > | should we be doing the same with the 6 SpSocket class vars
| as
| > | > | well?
| > | > | > |
| > | > | > | On Fri, Apr 23, 2010 at 3:27 PM, Dale Henrichs
| > | > | > | <[hidden email]> wrote:
| > | > | > | > Sean,
| > | > | > | >
| > | > | > | > I'm under the weather today ... nasty little cold ...
| SOAP
| > | and
| > | > | > | commit conflicts would be something that is likely to be
| > | problem,
| > | > | > | since I haven't really tested it under concurrent loads
| ...
| > | the
| > | > | quick
| > | > | > | fix would be to find any state that is kept in class vars
| and
| > | > | store in
| > | > | > | the SessionTemps dictionary (there are a number of
| examples
| > | if
| > | > | you
| > | > | > | look for references) ... There should be no need to keep
| > | anything
| > | > | in a
| > | > | > | Gobal, other than for convenience...
| > | > | > | >
| > | > | > | > Dale
| > | > | > | > ----- "Sean Allen" <[hidden email]> wrote:
| > | > | > | >
| > | > | > | > | Hi Dale,
| > | > | > | > |
| > | > | > | > | Neither Hernan or I right now knows how to intepret
| this.
| > | > | > | > | Basically, I executed some code to issue a refund via
| > | Chase
| > | > | > | > | Paymentech
| > | > | > | > | which is run over Soap.
| > | > | > | > | The refund went through and I went in gemtools to
| commit
| > | and
| > | > | got
| > | > | > | a
| > | > | > | > | write-write conflict with the following info in the
| > | > | Write-Write:
| > | > | > | > |
| > | > | > | > | anArray( SpSocket, SoapHttpClient, #'CrLf'->'')
| > | > | > | > |
| > | > | > | > | Any ideas on that?
| > | > | > | >
| > | > | >
| > | >
| >