|
Home > Archive > BizTalk Server General > May 2006 > SQL Adapter stops polling
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SQL Adapter stops polling
|
|
| Danderio 2005-10-13, 6:00 pm |
| Has anybody run into a SQL adapter receive port that stops polling for
no apparent reason? No errors in HAT. No errors in the event log. I
have to restart the Hosts to resume the polling.
Ideas would be apreciated!
| |
| Scott Colestock 2005-10-13, 6:00 pm |
| Do you have a very large number of polling receive locations active? If so,
consider consulting this article, which might be relevant with regard to
thread settings:
http://www.traceofthought.net/Perma...3aa3c84022.aspx
Scott Colestock
www.traceofthought.net
"Danderio" <danderio@hotmail.com> wrote in message
news:1129159738.691394.82550@g43g2000cwa.googlegroups.com...
> Has anybody run into a SQL adapter receive port that stops polling for
> no apparent reason? No errors in HAT. No errors in the event log. I
> have to restart the Hosts to resume the polling.
>
> Ideas would be apreciated!
>
| |
| chasmcg@aol.com 2005-10-24, 10:36 am |
| I was hoping this would fix my problem but no luck (as of 1 night of
testing). I have 4 Receive SQL Ports... They are timed at 23,31,59 and
61 seconds. Hopefully someone can add some other insights.
| |
| McGeeky 2005-10-28, 5:03 pm |
| Out of the blue a SQL receive port that had been working for months suddenly
stopped polling: no error messages. A BizTalk reboot cured it.
We are about to add a whole bunch more SQL receive ports so this is quite a
worrying turn up. My only thought is to use SQL Server jobs instead and have
them write out to a file which a BizTalk file adapter is listening to.
I'll try out this tip first but I am not holding my breath:
http://www.traceofthought.net/Perma...e4-bbe6-833aa3c
84022.aspx
--
McGeeky
http://mcgeeky.blogspot.com
<chasmcg@aol.com> wrote in message
news:1129322439.040298.143380@g14g2000cwa.googlegroups.com...
> I was hoping this would fix my problem but no luck (as of 1 night of
> testing). I have 4 Receive SQL Ports... They are timed at 23,31,59 and
> 61 seconds. Hopefully someone can add some other insights.
>
| |
| McGeeky 2005-10-28, 5:03 pm |
| Is there any direction from Microsoft on the SQL receive location issue?
There are several postings on this newsgroup by now about his problem.
--
McGeeky
http://mcgeeky.blogspot.com
"McGeeky" <anon@anon.com> wrote in message
news:Os5pPTw2FHA.3244@tk2msftngp13.phx.gbl...
> Out of the blue a SQL receive port that had been working for months
suddenly
> stopped polling: no error messages. A BizTalk reboot cured it.
>
> We are about to add a whole bunch more SQL receive ports so this is quite
a
> worrying turn up. My only thought is to use SQL Server jobs instead and
have
> them write out to a file which a BizTalk file adapter is listening to.
>
> I'll try out this tip first but I am not holding my breath:
>
http://www.traceofthought.net/Perma...e4-bbe6-833aa3c
> 84022.aspx
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> <chasmcg@aol.com> wrote in message
> news:1129322439.040298.143380@g14g2000cwa.googlegroups.com...
>
>
| |
| McGeeky 2005-10-31, 7:55 am |
| An update: I have since tried to reproduce this issue on a development box
but to no avail. I created 40 SQL Server receive locations - each one
updated a unique row in the database so I could so when it last ran. But
after running for several hours I didn't spot any problems.
This is bizarre as the production server where we experienced the problem
has only 4 SQL Server receive locations.
I have also tried tweaking the CLR Hosting key in the registry (as described
here:
http://www.traceofthought.net/Perma...3aa3c84022.aspx
) and set all the max values to 15 and min values to 10 in an attempt to
force the problem, but again, it didn't rear its ugly head.
I am beginning to think that this is not a straight forward threading
issue - but something a little more sinister and complex. Any anecdotal
evidence from others on this issue would be really useful.
We are running BizTalk 2004 Standard Edition SP1 on Windows 2003.
--
McGeeky
http://mcgeeky.blogspot.com
"McGeeky" <anon@anon.com> wrote in message
news:Os5pPTw2FHA.3244@tk2msftngp13.phx.gbl...
> Out of the blue a SQL receive port that had been working for months
> suddenly
> stopped polling: no error messages. A BizTalk reboot cured it.
>
> We are about to add a whole bunch more SQL receive ports so this is quite
> a
> worrying turn up. My only thought is to use SQL Server jobs instead and
> have
> them write out to a file which a BizTalk file adapter is listening to.
>
> I'll try out this tip first but I am not holding my breath:
> http://www.traceofthought.net/Perma...e4-bbe6-833aa3c
> 84022.aspx
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> <chasmcg@aol.com> wrote in message
> news:1129322439.040298.143380@g14g2000cwa.googlegroups.com...
>
>
| |
| McGeeky 2005-11-02, 7:52 am |
| Are you able to reproduce this issue consistently? We have experienced a
similar problem but it is not consistent - I cannot reproduce it on a
development PC despite creating 40 receive locations. It happened twice last
week on the production system but has since not happened again.
--
McGeeky
http://mcgeeky.blogspot.com
"Danderio" <danderio@hotmail.com> wrote in message
news:1129159738.691394.82550@g43g2000cwa.googlegroups.com...
> Has anybody run into a SQL adapter receive port that stops polling for
> no apparent reason? No errors in HAT. No errors in the event log. I
> have to restart the Hosts to resume the polling.
>
> Ideas would be apreciated!
>
| |
| Danderio 2005-11-02, 5:50 pm |
| I still dont know what is causing this, I havnt had the issue reoccur
in our production box, but it is still happening in my dev box. Even in
the dev box it happens about once per day. I dont know how to reproduce
it, it is very random. My app only has 2 receive SQL locations, but now
that I think of it, it only happens with one of them. That one has a
polling interval of 5 seconds, and it is polling the local database.
I've been following your research on this. Sorry for not being more
helpfull.
Dan
McGeeky wrote:[vbcol=seagreen]
> Are you able to reproduce this issue consistently? We have experienced a
> similar problem but it is not consistent - I cannot reproduce it on a
> development PC despite creating 40 receive locations. It happened twice last
> week on the production system but has since not happened again.
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Danderio" <danderio@hotmail.com> wrote in message
> news:1129159738.691394.82550@g43g2000cwa.googlegroups.com...
| |
| McGeeky 2005-11-02, 5:50 pm |
| Hi Dan,
Thanks for getting back. Its the worst kind of problem because it is so
random. I simply cannot reproduce it. You mention your polling interval was
set to 5 seconds - I had 40 with polling intervals set at anywhere between
10 and 40 seconds but didn't experience any issues at all. Yet you have run
in to the problem with only 2! What gives???
Do you have any other ports set up using different adapters? On our
production box where the problem manifested itself we use only one FTP
receive and one FTP send, about 8 FILE receives and 4 FILE sends, one HTTP
send/receive port, one SMTP send port , 3 SQL receive ports (60 second
intervals), 5 SQL send ports, and also a couple of Covast AS2 ports. I
sometimes wonder whether those other adapters are misbehaving and causing
problems for the SQL adapter.
I set up a SQL Profiler template to monitor the stored procedure calls - but
seeing as it has never happened again its not been useful. I wonder if you
can set one up on your development PC and leave it running throughout the
day? It could identify exactly when it stopped polling and perhaps you can
correlate that with some other event/activity that occurred?
Stay in touch. If you find out any more then please post back - I'll do the
same.
--
McGeeky
http://mcgeeky.blogspot.com
"Danderio" <danderio@hotmail.com> wrote in message
news:1130951269.014189.129290@g44g2000cwa.googlegroups.com...
> I still dont know what is causing this, I havnt had the issue reoccur
> in our production box, but it is still happening in my dev box. Even in
> the dev box it happens about once per day. I dont know how to reproduce
> it, it is very random. My app only has 2 receive SQL locations, but now
> that I think of it, it only happens with one of them. That one has a
> polling interval of 5 seconds, and it is polling the local database.
>
> I've been following your research on this. Sorry for not being more
> helpfull.
>
> Dan
>
>
> McGeeky wrote:
last[vbcol=seagreen]
>
| |
| McGeeky 2005-11-08, 6:20 pm |
| An update: the problem has not recurred yet on the production server but I
have noticed what appears to be a "thread leak". Over the past week I have
been monitoring the number of threads consumed by the BizTalk service on the
production machine and it has steadily grown.
I am using perfmon to monitor the following .Net counters of the BizTalk
service:
1. # of current logical Threads
2. # of current physical Threads
3. # of current recognized threads
4. # of total recognized threads
This is what has happened over the course of a week:
1. Current logical threads has grown from 45 to 60
2. Current physical threads has remained static
3. Current recognized threads has grown from 18 to 33
4. Total recognized threads has grown from 110 to well over 200 but I don't
think this is important as it is a tally of previous activity rather than
showing the state of current activity
I would have thought that threads should be released much like memory is -
but it looks like this is not the case. I'll continue monitoring the
situation and report back.
Anyone with an opinion or experience with "thread leaks" and BizTalk? Could
there be something in this?
Thanks
--
McGeeky
http://mcgeeky.blogspot.com
"McGeeky" <anon@anon.com> wrote in message
news:%23MMSRN$3FHA.1420@TK2MSFTNGP09.phx.gbl...
> Hi Dan,
>
> Thanks for getting back. Its the worst kind of problem because it is so
> random. I simply cannot reproduce it. You mention your polling interval
> was
> set to 5 seconds - I had 40 with polling intervals set at anywhere between
> 10 and 40 seconds but didn't experience any issues at all. Yet you have
> run
> in to the problem with only 2! What gives???
>
> Do you have any other ports set up using different adapters? On our
> production box where the problem manifested itself we use only one FTP
> receive and one FTP send, about 8 FILE receives and 4 FILE sends, one HTTP
> send/receive port, one SMTP send port , 3 SQL receive ports (60 second
> intervals), 5 SQL send ports, and also a couple of Covast AS2 ports. I
> sometimes wonder whether those other adapters are misbehaving and causing
> problems for the SQL adapter.
>
> I set up a SQL Profiler template to monitor the stored procedure calls -
> but
> seeing as it has never happened again its not been useful. I wonder if you
> can set one up on your development PC and leave it running throughout the
> day? It could identify exactly when it stopped polling and perhaps you can
> correlate that with some other event/activity that occurred?
>
> Stay in touch. If you find out any more then please post back - I'll do
> the
> same.
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Danderio" <danderio@hotmail.com> wrote in message
> news:1130951269.014189.129290@g44g2000cwa.googlegroups.com...
> last
>
>
| |
| Navnit Mehta 2006-01-13, 9:59 pm |
| I have started facing the same problem after applying SP1 on the production.
And its very random.
Any one got it solved ??
--
Once you open a can of worms, the only way to recan them is to use a larger
can
"McGeeky" wrote:
> An update: the problem has not recurred yet on the production server but I
> have noticed what appears to be a "thread leak". Over the past week I have
> been monitoring the number of threads consumed by the BizTalk service on the
> production machine and it has steadily grown.
>
> I am using perfmon to monitor the following .Net counters of the BizTalk
> service:
> 1. # of current logical Threads
> 2. # of current physical Threads
> 3. # of current recognized threads
> 4. # of total recognized threads
>
> This is what has happened over the course of a week:
> 1. Current logical threads has grown from 45 to 60
> 2. Current physical threads has remained static
> 3. Current recognized threads has grown from 18 to 33
> 4. Total recognized threads has grown from 110 to well over 200 but I don't
> think this is important as it is a tally of previous activity rather than
> showing the state of current activity
>
> I would have thought that threads should be released much like memory is -
> but it looks like this is not the case. I'll continue monitoring the
> situation and report back.
>
> Anyone with an opinion or experience with "thread leaks" and BizTalk? Could
> there be something in this?
>
> Thanks
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "McGeeky" <anon@anon.com> wrote in message
> news:%23MMSRN$3FHA.1420@TK2MSFTNGP09.phx.gbl...
>
>
>
| |
| McGeeky 2006-01-13, 9:59 pm |
| We are still experiencing this problem - its very annoying.
BTW. Are you making use of the business rules engine at all?
--
McGeeky
http://mcgeeky.blogspot.com
"Navnit Mehta" <NavnitMehta@discussions.microsoft.com> wrote in message
news:63F37809-284A-46FF-9195-C117CF047186@microsoft.com...[vbcol=seagreen]
>I have started facing the same problem after applying SP1 on the
>production.
> And its very random.
>
> Any one got it solved ??
> --
> Once you open a can of worms, the only way to recan them is to use a
> larger
> can
>
>
> "McGeeky" wrote:
>
| |
| Marian Drumea [MVP] 2006-01-13, 9:59 pm |
| Hi,
What is the state of the SQL Server in terms of deadlocks? How
optimized are the queries? Is the previous call to the SQL Server done,
returning the results by the time the next scheduled one kicks in?
The fact that it was working before and not now doesn't help too much
if the queries are made against a growing database, locking
rows/pages/tables/DB and maybe concurrently with other applications. Do
you use table hints in your calls?
Also, on the BizTalk front, if you turned on additional tracking and
have an issue with the processes, BizTalk will be very busy writing
that large amount of data and the BizTalk databases will be soon
showing deadlocks. Also, I guess you have retries on your ports, so it
will be like a spiral if, again, there is a problem in processing the
messages. Server restart would also help, confirming the theory,
because it will force a checkpoint on the database, close all
connections, and remove the locks. Only until next time ...
Please check the deadlocks on your solution database(s), but also on
the BizTalk ones (performance monitor?), check the queries from your
application in SQL Query Analyzer, keep an eye on the calls in SQL
Profiler and see whether the calls are actually made at the right
times, but you don't get anything back because of the locks, etc. I am
trying seeing the exact situation, but this is what I would start with.
Thanks,
Marian Drumea [MVP]
http://www.MarianDrumea.com
| |
| Navnit Mehta 2006-01-13, 9:59 pm |
|
I dont have any tracking enabled on any of the SQL receive ports. I
restarted the server once and had the same problem almost on the same day,
then I disabled and enabled the receive port and things and fine so far.
I had some sp's which would run in to deadlock's. I have made the changes
and keeping my fingers crossed. I am also going to run the profilier and see
what I can get.
But one thing that I am still not clear about is that why has this problem
started occuring after applying BTS SP1, I have never had such a problem
before BTS SP1. I have the same amount of data as before since I transfer all
the data to history everyday, so there is no possibility of data size growing
bigger causing deadlock.
I'll keep you all posted.
--
Once you open a can of worms, the only way to recan them is to use a larger
can
"Marian Drumea [MVP]" wrote:
> Hi,
>
> What is the state of the SQL Server in terms of deadlocks? How
> optimized are the queries? Is the previous call to the SQL Server done,
> returning the results by the time the next scheduled one kicks in?
>
> The fact that it was working before and not now doesn't help too much
> if the queries are made against a growing database, locking
> rows/pages/tables/DB and maybe concurrently with other applications. Do
> you use table hints in your calls?
>
> Also, on the BizTalk front, if you turned on additional tracking and
> have an issue with the processes, BizTalk will be very busy writing
> that large amount of data and the BizTalk databases will be soon
> showing deadlocks. Also, I guess you have retries on your ports, so it
> will be like a spiral if, again, there is a problem in processing the
> messages. Server restart would also help, confirming the theory,
> because it will force a checkpoint on the database, close all
> connections, and remove the locks. Only until next time ...
>
> Please check the deadlocks on your solution database(s), but also on
> the BizTalk ones (performance monitor?), check the queries from your
> application in SQL Query Analyzer, keep an eye on the calls in SQL
> Profiler and see whether the calls are actually made at the right
> times, but you don't get anything back because of the locks, etc. I am
> trying seeing the exact situation, but this is what I would start with.
>
> Thanks,
>
> Marian Drumea [MVP]
> http://www.MarianDrumea.com
>
>
| |
| Karlid 2006-01-27, 9:28 pm |
| Hi,
We are seeing this behaviour on one of our virtual development pc's.
Not much more insight to offer at this time unfortunately but the
pattern is intermittent and matches that described above. SP1, too.
| |
| McGeeky 2006-01-27, 9:28 pm |
| What other adapters and BizTalk technologies are you using in conjunction
with the SQL Adapter (eg. EDI, FTP, Business Rules Engine)?
My hunch is that either there is a problem with thread deadlocks inside the
SQL Adapter itself, or other adapters are behaving badly by not releasing
threads and therefore starving the SQL Adapter.
There are no messages as at all in the event logs, nothing in the HAT - no
indication at all as to what has happened.
If anyone can reliably reproduce this error then please post to this
newsgroup and I'll submit it to Microsoft as a support incident.
This bug is really annoying and it is taking a hit on my client's confidence
in BizTalk.
--
McGeeky
http://mcgeeky.blogspot.com
"Karlid" <karlid@yahoo.com> wrote in message
news:1138327307.629900.135150@g43g2000cwa.googlegroups.com...
> Hi,
>
> We are seeing this behaviour on one of our virtual development pc's.
> Not much more insight to offer at this time unfortunately but the
> pattern is intermittent and matches that described above. SP1, too.
>
| |
| McGeeky 2006-02-10, 7:48 am |
| An update for those of you still experiencing this issue (and by the way we
have found it is affecting the FTP receive port too)...
We are in the process of testing a hot fix from Microsoft to correct the
problem. We won't know for a few weeks whether it is successful or not
because that's how infrequently the problem occurs.
Will post back here once we have conclusive proof the hotfix does or doesn't
work.
--
McGeeky
http://mcgeeky.blogspot.com
"McGeeky" <anon@anon.com> wrote in message
news:uL$CDt2IGHA.1848@TK2MSFTNGP12.phx.gbl...
> What other adapters and BizTalk technologies are you using in conjunction
> with the SQL Adapter (eg. EDI, FTP, Business Rules Engine)?
>
> My hunch is that either there is a problem with thread deadlocks inside
> the
> SQL Adapter itself, or other adapters are behaving badly by not releasing
> threads and therefore starving the SQL Adapter.
>
> There are no messages as at all in the event logs, nothing in the HAT - no
> indication at all as to what has happened.
>
> If anyone can reliably reproduce this error then please post to this
> newsgroup and I'll submit it to Microsoft as a support incident.
>
> This bug is really annoying and it is taking a hit on my client's
> confidence
> in BizTalk.
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Karlid" <karlid@yahoo.com> wrote in message
> news:1138327307.629900.135150@g43g2000cwa.googlegroups.com...
>
>
>
| |
| Kevin J Mackey 2006-02-27, 5:51 pm |
| I look forward to seeing how things go with this.
On a system with 4 SQL Receive locations I have begun to notice the same
problem - no trace of error in HAT or event log, just seeming non-execution
of the stored procedure that returns the next message on which to operate.
Disable/Enable of the receive location clears it - until the hang happens
again, at some random interval.
--
KjM
"McGeeky" wrote:
> An update for those of you still experiencing this issue (and by the way we
> have found it is affecting the FTP receive port too)...
>
> We are in the process of testing a hot fix from Microsoft to correct the
> problem. We won't know for a few weeks whether it is successful or not
> because that's how infrequently the problem occurs.
>
> Will post back here once we have conclusive proof the hotfix does or doesn't
> work.
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "McGeeky" <anon@anon.com> wrote in message
> news:uL$CDt2IGHA.1848@TK2MSFTNGP12.phx.gbl...
>
>
>
| |
| McGeeky 2006-02-27, 5:51 pm |
| Are you running on Windows 2003 SP1 by any chance?
--
McGeeky
http://mcgeeky.blogspot.com
"Kevin J Mackey" <KevinJMackey@discussions.microsoft.com> wrote in message
news:10411D0D-AB52-417D-9B2B-59A57BEF99DD@microsoft.com...
> I look forward to seeing how things go with this.
>
> On a system with 4 SQL Receive locations I have begun to notice the same
> problem - no trace of error in HAT or event log, just seeming
non-execution[vbcol=seagreen]
> of the stored procedure that returns the next message on which to operate.
>
> Disable/Enable of the receive location clears it - until the hang happens
> again, at some random interval.
> --
> KjM
>
>
> "McGeeky" wrote:
>
we[vbcol=seagreen]
doesn't[vbcol=seagreen]
conjunction[vbcol=seagreen]
inside[vbcol=seagreen]
releasing[vbcol=seagreen]
HAT - no[vbcol=seagreen]
| |
| Kevin J Mackey 2006-02-27, 5:51 pm |
| Yes, indeed we are. So that has a bearing on this?
--
KjM
"McGeeky" wrote:
> Are you running on Windows 2003 SP1 by any chance?
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Kevin J Mackey" <KevinJMackey@discussions.microsoft.com> wrote in message
> news:10411D0D-AB52-417D-9B2B-59A57BEF99DD@microsoft.com...
> non-execution
> we
> doesn't
> conjunction
> inside
> releasing
> HAT - no
>
>
>
| |
| McGeeky 2006-02-28, 7:49 am |
| We have not experienced the problem since applying the patch but then we
have only been running with it for a week. We should know for definite after
a couple more weeks.
The cause (I must stress that this is only supposition from Microsoft at
this stage) is the .Net Timer class that the SQL receive locations use.
There is a bug with the Timer class that only manifests itself on Windows
Server 2003 Service Pack 1. Apparently under high load (and sometimes not
under high load as we have found) a given Timer object fails to fire - and
subsequently never fires. The Timer object somehow gets confused as to the
last time it was fired. Because the SQL receive locations use the Timer
classes to wake them up, if the Timer never fires then the receive location
will never be woken up to check the database.
Makes perfect sense really. I am crossing my fingers that this is the cause.
As I say, only time will tell. For those that want to try it out for
themselves this is a link to the knowledge base article for a hot fix to
correct the Timer issue - http://support.microsoft.com/?kbid=900822. As far
as I know this issue has not been linked to BizTalk and SQL receive
locations before now. I am surprised that more people have not reported it
as a problem.
Note that before I said that our FTP receive locations were also being
affected. Well we have since found that the cause for the FTP receive
locations stalling was an unrelated issue due to a compatibility problem
between the BizTalk FTP receive location and the FTP server it was
connecting to.
Please let me know how you get on if you do try out the hot fix. This has
been a nasty little bug that I would so like to see resolved!!
--
McGeeky
http://mcgeeky.blogspot.com
"Kevin J Mackey" <KevinJMackey@discussions.microsoft.com> wrote in message
news:8AFDFEA1-FEDD-4A91-BE5B-950B14C2CA9C@microsoft.com...[vbcol=seagreen]
> Yes, indeed we are. So that has a bearing on this?
>
> --
> KjM
>
>
> "McGeeky" wrote:
>
| |
| Kevin J Mackey 2006-03-27, 8:38 am |
| Sorry for not getting back to this - but this seems to have been the problem
and resolution. Applying the fix for the Timer cleared the BizTalk SQL
Adapter problem - it has been running for the past few weeks without problem.
Many thanks to all who chased this one down.
--
KjM
"McGeeky" wrote:
> We have not experienced the problem since applying the patch but then we
> have only been running with it for a week. We should know for definite after
> a couple more weeks.
>
> The cause (I must stress that this is only supposition from Microsoft at
> this stage) is the .Net Timer class that the SQL receive locations use.
> There is a bug with the Timer class that only manifests itself on Windows
> Server 2003 Service Pack 1. Apparently under high load (and sometimes not
> under high load as we have found) a given Timer object fails to fire - and
> subsequently never fires. The Timer object somehow gets confused as to the
> last time it was fired. Because the SQL receive locations use the Timer
> classes to wake them up, if the Timer never fires then the receive location
> will never be woken up to check the database.
>
> Makes perfect sense really. I am crossing my fingers that this is the cause.
> As I say, only time will tell. For those that want to try it out for
> themselves this is a link to the knowledge base article for a hot fix to
> correct the Timer issue - http://support.microsoft.com/?kbid=900822. As far
> as I know this issue has not been linked to BizTalk and SQL receive
> locations before now. I am surprised that more people have not reported it
> as a problem.
>
> Note that before I said that our FTP receive locations were also being
> affected. Well we have since found that the cause for the FTP receive
> locations stalling was an unrelated issue due to a compatibility problem
> between the BizTalk FTP receive location and the FTP server it was
> connecting to.
>
> Please let me know how you get on if you do try out the hot fix. This has
> been a nasty little bug that I would so like to see resolved!!
>
> --
> McGeeky
> http://mcgeeky.blogspot.com
>
>
> "Kevin J Mackey" <KevinJMackey@discussions.microsoft.com> wrote in message
> news:8AFDFEA1-FEDD-4A91-BE5B-950B14C2CA9C@microsoft.com...
>
>
>
| |
| Henrik Olsson 2006-05-10, 7:17 am |
| "McGeeky" wrote:
> Note that before I said that our FTP receive locations were also being
> affected. Well we have since found that the cause for the FTP receive
> locations stalling was an unrelated issue due to a compatibility problem
> between the BizTalk FTP receive location and the FTP server it was
> connecting to.
Can you provide some details about this? We have a problem with FTP receive
locations stalling.
| |
| McGeeky 2006-05-10, 1:15 pm |
| We are accessing an FTP server hosted by our trading partner called ProFTPD
(http://www.proftpd.org). Its an Open Source FTP server. We never did get to
the bottom of what the issue was so are simply living with it - having to
restart the BizTalk service each time the FTP receive location freezes.
Microsoft found that the BizTalk FTP receive location was freezing in the
connect method but could not explain why.
If I have the time I will reopen the case with Microsoft - but as of now I
don't have a resolution for it.
Which FTP server are you accessing? Note that we have never had a problem
connecting to Windows' FTP server.
--
McGeeky
http://mcgeeky.blogspot.com
"Henrik Olsson" <Henrik Olsson@discussions.microsoft.com> wrote in message
news:87348017-D6DA-49D5-A794-AD19F21F74D3@microsoft.com...
> "McGeeky" wrote:
>
>
> Can you provide some details about this? We have a problem with FTP
> receive
> locations stalling.
>
| |
| Henrik Olsson 2006-05-11, 7:15 am |
| We're accessing both Windows and Unix FTP servers, and have seen the problem
on both, so it seems likely that it is the timer bug that is the cause.
Henrik
| |
| McGeeky 2006-05-12, 7:14 am |
| In your case it sounds like it could be. Definitely worth applying the
hotfix.
--
McGeeky
http://mcgeeky.blogspot.com
"Henrik Olsson" <HenrikOlsson@discussions.microsoft.com> wrote in message
news:8D0F160B-6F80-4859-AAC4-49538CF963B1@microsoft.com...
> We're accessing both Windows and Unix FTP servers, and have seen the
> problem
> on both, so it seems likely that it is the timer bug that is the cause.
>
> Henrik
| |
| rene.rugerio@gmail.com 2006-05-22, 7:14 pm |
| McGeeky !!
I have red all the post about this hotfix, and navigated to the link
you provided, but cant access the files, it says that i must contact
some microsoft representative in order to do so.
Im having the exact same problem with a receive location using the ftp
adapter, and matching the syntoms, i agree is the same cause you were
talking about.
Please, can you send me the hotfix to my inbox
"rene.rugerio" at google gmail
| |
| McGeeky 2006-05-22, 7:14 pm |
| I am not sure if I am permitted to do that. Does it invalidate the license
terms under which I received the hotfix? Usually you get hotfixes if you
have a support agreement or log a specific support incident (which will not
be charged because it is a bug with the code in this case).
--
McGeeky
http://mcgeeky.blogspot.com
<rene.rugerio@gmail.com> wrote in message
news:1148330028.982653.8010@i39g2000cwa.googlegroups.com...
> McGeeky !!
> I have red all the post about this hotfix, and navigated to the link
> you provided, but cant access the files, it says that i must contact
> some microsoft representative in order to do so.
> Im having the exact same problem with a receive location using the ftp
> adapter, and matching the syntoms, i agree is the same cause you were
> talking about.
>
> Please, can you send me the hotfix to my inbox
> "rene.rugerio" at google gmail
>
| |
| rene.rugerio@gmail.com 2006-05-23, 1:15 am |
| well, this is like a dead end alley because it seems to stop randomly
i might try getting help from microsoft guys, in the meantime i will
try about increasing the polling interval in the receive locations
which may give me time to reach for a dot net framework service pack
i will have to deal with some kind of service restarting my biztalk
services instances in the meantime
thank you, mcgeeky
|
|
|
|
|