Select the search type
  • Site
  • Web
Search
You are here:  Support/Forums
Support

Bring2mind Forums

lots of error
Last Post 11/27/2009 5:28 PM by Peter Donker. 15 Replies.
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Nathan
New Member
New Member
Posts:10


--
10/21/2009 2:59 AM

I keep getting 4 errors over and over I disabled the 3 task DMX task in the Scheduler  and all 4 errors stoped. Here are the 4 errors:

ERROR 1

THREAD ID: 25
TYPE: Bring2mind.DNN.Modules.DMX.Framework.SyncFolderTask
EXCEPTION: Thread was being aborted.
RESCHEDULED FOR: 1/1/0001 12:10:00 AM
SOURCE: STARTED_FROM_BEGIN_REQUEST
ACTIVE THREADS: -5
FREE THREADS: 6
READER TIMEOUTS: 322
WRITER TIMEOUTS: 117
IN PROGRESS: 0
IN QUEUE: 8
Server Name: VIMSWEB01

ERROR 2

AssemblyVersion: 5.1.1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: 00066356-ea3d-410c-a6e5-59c5b4ea530d
InnerException: Thread was being aborted.
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: DotNetNuke.Services.Scheduling.DNNScheduling.CoreScheduler.WorkStarted
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.WorkStarted(SchedulerClient& objSchedulerClient) at DotNetNuke.Services.Scheduling.SchedulerClient.Started() at DotNetNuke.Services.Scheduling.DNNScheduling.ProcessGroup.Run(ScheduleHistoryItem objScheduleHistoryItem)
Source:
Server Name: VIMSWEB01

 

ERROR 3

AssemblyVersion: 5.1.1
PortalID: 0
PortalName: VistaIMS, LLC
UserID: 1
UserName: vimshost
ActiveTabID: 25
ActiveTabName: Schedule
RawURL: /tabid/25/ctl/Edit/mid/332/ScheduleID/19/portalid/0/Default.aspx
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer: http://vistaims.com/tabid...talid/0/Default.aspx
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: db8a4bfc-9004-4b5f-9f88-b31b6f87742a
InnerException: This operation returned because the timeout period expired. (Exception from HRESULT: 0x800705B4)
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: System.Threading.ReaderWriterLock.AcquireWriterLockInternal
StackTrace:
Message: System.ApplicationException: This operation returned because the timeout period expired. (Exception from HRESULT: 0x800705B4) at System.Threading.ReaderWriterLock.AcquireWriterLockInternal(Int32 millisecondsTimeout) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.RemoveFromScheduleQueue(ScheduleItem objScheduleItem)
Source:
Server Name: VIMSWEB01

ERROR 4

 
AssemblyVersion: 5.1.1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: ddd0f7ca-9c5a-419c-aada-3862c3c33cc6
InnerException: Thread was being aborted.
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: System.Threading.ReaderWriterLock.AcquireReaderLockInternal
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.ReaderWriterLock.AcquireReaderLockInternal(Int32 millisecondsTimeout) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.IsInQueue(ScheduleItem objScheduleItem) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.LoadQueueFromTimer() at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.Start()
Source:
Server Name: VIMSWEB01

 

I also hove problems when uploading files, the file uploads just fine but when i get to the permissions there all grayed out. and when i click on Finish button it can take 2 minutes or more. them i go to the file and click and Edit Attributes the Permissions are still grayed out.

Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
10/27/2009 10:54 AM
Hi Nathan,

The scheduler errors do not look familiar. If you're not using any sync folders then you can safely turn off the task to avoid this. If you use them the error needs to be resolved. It looks like an internal error within the scheduler as it tries to lock itself. As far as I can tell the error was not induced by code specific to the sync folders.

The greyed out boxes are due to errors in the DMX_PermissionPermissions, meaning that the portal somehow has switched the roles of 'Administrator' and 'Registered Users'. Contact me by email to see about a fix.

Peter
Nathan
New Member
New Member
Posts:10


--
10/27/2009 6:07 PM
ok we have not had any error in the past 24 hr. :). so now i would like to figer out why DMX is running so slow. even browsing to the page that has DMX on it is slow to load. uploading files is fast but any time i got to edit attributes and --> Permissions and click on Finish it takes up to 2 minutes. infact any time i click on that Finish button it take 2 minutes.
Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
10/28/2009 4:25 PM
Hi Nathan,

It could be DNN 5.1.1 that is interfering. I'm currently working to see what might be causing some customers to report performance issues on DNN 5 installations.

Peter
Chris Smith
New Member
New Member
Posts:68


--
11/04/2009 1:22 PM

Peter,

 

Has there been any progress on this issue. We have the same problem on two installations on two different servers.

Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
11/06/2009 4:44 PM
We are still working to actually replicate some of these findings. Until now we have not identified an issue with 05.01.04 that causes DMX to slow down. But maybe there's a third party component that is interfering.

Peter
Nathan
New Member
New Member
Posts:10


--
11/08/2009 9:00 PM
ok so if we can get ever one that is having the problem to send you a list of their installed modules, then send me a list of the common denominators. I will set up a new install of DNN on our test server and install them one at a time until DMX stops working.
Nathan
New Member
New Member
Posts:10


--
11/13/2009 10:06 PM
We have set up a test server with a new install of DNN 5. I then installed most of our modules and everything is working good still. The one module i have not yet installed because we no longer use it. is DNNMasters SEO URL Provider (ML). we had lots of problems with this module. it took down your server for 2 day. is anyone ells using this or tried to use this module. it was a long time ago so i do not remember if DMX was working before this or if we even had it installed at that time.

I am not sure just installing the module will brake DMX or i will need to try and duplicate the crash. grrrrr
Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
11/19/2009 12:58 PM
Hi Nathan,

Thanks for sharing the info. If you absolutely need it you might contact the vendor to get more info why it would break our module. Maybe they have an insight.

Good luck,

Peter
Chris Smith
New Member
New Member
Posts:68


--
11/19/2009 2:23 PM

This is not the case with us. We have 3 production installations which all have the error. NONE of the use DNNMasters SEO URL Provider. So we may need to broden our search. The only thing that all three installs have in common is that they run in virtual machines (VMWare Infrastructure). All three are on different VM's/Servers, however none are cloned so they are unique machines.

Nathan
New Member
New Member
Posts:10


--
11/19/2009 5:11 PM

We are also running VMWare. You may be on to something there. We have three boxs set up 1 test not running on VMWare. Stage it is running on a dell running VMWare, and our Live server is also on a dell running VMWare. Stage an Prog are boath having problems. but Test is running with out any problems.

Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
11/24/2009 10:51 AM
Chris/Nathan,

Just to make sure we're on the same page: are we still talking about performance issues here?

Peter
Chris Smith
New Member
New Member
Posts:68


--
11/24/2009 12:33 PM
No, for me performance is fine. I'm speaking of the AcquireWriterLockInternal CoreScheduler error that reoccurs in the eventlog.
nathan
New Member
New Member
Posts:1


--
11/24/2009 5:56 PM
I am talking about boath. the errors are more of an annoyance for use but the performance problem making DMX unuseble.
Chris Smith
New Member
New Member
Posts:68


--
11/24/2009 10:37 PM

Again, performance for me is not an issue. I have one installation that does pretty good traffic (a little over a GB a day) most of which is documents/presentations for the document manager.

They are also on different OS's, 2 are Windows 2008 R2 and one is a Windows 2003 R2. All have 3GB of RAM and AMD Opteron 2356 processors.

Peter Donker
Veteran Member
Veteran Member
Posts:4536


--
11/27/2009 5:28 PM
Hi guys,

Chris:
The AcquireWriterLockInternal error from the original post did not originate in DMX. Note the SyncFolder code has been hardened for DMX 5.2.

Nathan:
There are 2 possible issues: one is a general DNN 5 issue of which I'm not sure if it is being tackled right now. It has to do with how user data is managed. I'm still trying to find out if this is impacting DMX. It was brought to my attention by a fellow mod developer at OpenForce US.
The other issue is in WebDAV and with a large DMX_Log. This will be solved in DMX 5.2.
If this still does not point in the right direction then contact me through email so maybe I can have a look and we could even run a test on a copied server (if you're running VMWare) with the DMX 5.2 beta to see if it improves.

Peter

You are not authorized to post a reply.