Jump to content

Data file size limit


ReminderVDP

Recommended Posts

I want to know if anyone else has had trouble composing to FusionPro Producer with a data file over 200 MB? Until the last couple weeks, I've had no problem writing records of 50,000 with a file size of 200MB+. I reinstalled FusionPro on my MacBook Pro running 10.8.5 and FusionPro 9.0 and it still will not let me write 50,000 records. It gives me a "Cannot Submit Job" error from the server. Files slightly under 200 MB will work. I composed one that was 194 MB and had 44,655 records. It doesn't make sense that it would just stop working.
Link to comment
Share on other sites

Does the job fail as soon as you submit it or does it compose some records and then fail?

 

The former would lead me to believe that it's an issue with Producer (though I wouldn't think file size would have any impact on that) while the latter would hint at not having enough RAM on the Producer computer to compose the job.

 

You could also split the data files into chunks and compose that way.

Link to comment
Share on other sites

step,

It fails before the job even queues. It started about 3 weeks ago so this is new. It worked fine until then. We chunk our records at 50,000 because anything over that fails instantly. Now, we have had to break those down into 25,000 records which is scary because we are breaking up the data after the fact. Breaking it down lower than 50,000 is an issue for reprints and composition since our license is for 3 jobs at a time. We have print runs over 125,000 which would have us compose 5 or 6 files instead of 3.

Link to comment
Share on other sites

I don't know if this follows along with your specific posting since I don't run from my Mac too much anymore, but I have noticed that FusionPro is very memory intensive. A large data file might cause problems. I've even caused our FusionPro Server to crash once I get files over 400,000 - even when I batch them into smaller segments on output. As each record reads in FusionPro just keeps using more and more memory until the machine simply crashes or the final record is read in and composed.

 

I've been having problems like this since back in the days of FusionPro 3.0. I was under the impression back then that once a "batched output file" was written that FusionPro would have cleared out the memory before continuing on. It seems that PTI still has not dealt too much with that.

 

Check the memory usage of your machine as you are composing or when you hit your submit button and see what is going on.

Link to comment
Share on other sites

  • 2 weeks later...
I don't know if this follows along with your specific posting since I don't run from my Mac too much anymore, but I have noticed that FusionPro is very memory intensive. A large data file might cause problems. I've even caused our FusionPro Server to crash once I get files over 400,000 - even when I batch them into smaller segments on output. As each record reads in FusionPro just keeps using more and more memory until the machine simply crashes or the final record is read in and composed.

 

I've been having problems like this since back in the days of FusionPro 3.0. I was under the impression back then that once a "batched output file" was written that FusionPro would have cleared out the memory before continuing on. It seems that PTI still has not dealt too much with that.

 

Check the memory usage of your machine as you are composing or when you hit your submit button and see what is going on.

 

What is the physical size of these large data files that you're running if you don't mind my asking? Our data files are typically in the 300-400mb range.

 

Support gave us a workaround of recomposing from the Fusion Pro Direct Monitor application and choosing the larger data file. Which works to an extent. The 50k file will compose this way but the 100k file still fails even with the workaround. To me that points to something on the server side with the physical size of the file. I'm curious as to the file sizes that some of you are using.

Link to comment
Share on other sites

It's not an issue of the size of the file on "the server side," nor the number of records. We routinely run jobs with hundreds of thousands of records through the Producer API (FP Server). FusionPro does not attempt to read the entire data file into memory at any given time; it reads one record at a time from disk and composes it, then releases that memory. (With imposition, it remembers the offset into the data file for each record, then seeks to the appropriate location as it's composing records on each output sheet.) Generally, large memory usage is due to graphics. But if you are having trouble with memory usage increasing, I would try FusionPro 9 to see if that works better for you.

 

The problem/limitation is in the transfer of the data from the client machine to the server. This might be due to limits that the operating system puts on the amount of data that can be transferred at any given time. Or, it might be a problem in the Mac implementation of the Producer Monitor app. You could try re-submitting the job from the Monitor app on a Windows machine, such as the server itself.

Link to comment
Share on other sites

I would try FusionPro 9 to see if that works better for you.

 

The problem/limitation is in the transfer of the data from the client machine to the server. This might be due to limits that the operating system puts on the amount of data that can be transferred at any given time. Or, it might be a problem in the Mac implementation of the Producer Monitor app. You could try re-submitting the job from the Monitor app on a Windows machine, such as the server itself.

 

We are using Fusion Pro 9.0.3

 

I agree that the problem is in the transfer of the data from the client to the server. I have just tested doing a recompose from the monitor application at the server itself and that works. It still fails from either Mac. I also ran a recompose from a Windows 7 PC on the same network. That worked. A compose of the job from the same PC also works fine.

 

So my question is what is the problem in the Mac client to server workflow and can it be fixed? The Macs are connecting to the server via samba.

Link to comment
Share on other sites

Dan,

We are running FusionPro 9.0 already, I stated this on the thread with the operating system we are using. Do your jobs that you run with hundreds of thousands of records have over 200 data fields per record and are filled with images?

 

None of the explanations Support is giving us explain why my MacBook pro would all the sudden stop composing 50,000 records with a data file that is 215 MB. It worked fine for 8 months and stopped working 3 weeks ago. We can't upgrade the operating system because Mavericks isn't supported.

Link to comment
Share on other sites

We are using Fusion Pro 9.0.3

We are running FusionPro 9.0 already, I stated this on the thread with the operating system we are using.

Yeah, I can see that you guys are running FusionPro 9 on your Macs. Step mentioned that he's seeing high memory usage in FusionPro 8, which was why I suggested he might want to try 9. Also, other than Step, nobody has specified the version of Windows they're running Producer on, nor what version of FusionPro is running on the Windows server.

I agree that the problem is in the transfer of the data from the client to the server. I have just tested doing a recompose from the monitor application at the server itself and that works. It still fails from either Mac. I also ran a recompose from a Windows 7 PC on the same network. That worked. A compose of the job from the same PC also works fine.

Okay, so it's not a problem with FusionPro being able to handle large data files in general then.

So my question is what is the problem in the Mac client to server workflow and can it be fixed?

Yes, that is the question. Unfortunately, I don't know off of the top of my head exactly what the problem is or how it can be fixed. The ever-changing Mac OS X system APIs are a constant challenge to keep up with. I will tell you, though, that there are limitations in the Producer system, some of which can be gotten around only by using the Producer API (FP Server).

The Macs are connecting to the server via samba.

You may indeed be connecting to the server via Samba with the Finder, but that's not at all relevant to how the Monitor app is connecting to it, which is via low-level TCP sockets.

Do your jobs that you run with hundreds of thousands of records have over 200 data fields per record and are filled with images?

We do run jobs with hundreds of thousands of records, and with large images. As for 200 data fields, I don't think we have a job like that. Is FusionPro really using all those fields?

None of the explanations Support is giving us explain why my MacBook pro would all the sudden stop composing 50,000 records with a data file that is 215 MB. It worked fine for 8 months and stopped working 3 weeks ago.

Okay, well, I don't know exactly what correspondence you have had with Support. But you can't just call up the auto shop and tell them that your car is making a funny noise, and demand that they diagnose the problem over the phone. Why would something suddenly stop working? I don't know. I would have to start by asking you what changed on your system.

 

Also, do you mean that FusionPro won't compose those 50,000 records directly on your Mac, or that it won't compose them via Producer?

We can't upgrade the operating system because Mavericks isn't supported.

Mavericks support is coming soon, with FusionPro 9.2. However, the Monitor app probably will still not be supported on Mavericks in the initial 9.2 release.

Link to comment
Share on other sites

 

You may indeed be connecting to the server via Samba with the Finder, but that's not at all relevant to how the Monitor app is connecting to it, which is via low-level TCP sockets.

 

 

I'm not suggesting that I can troubleshoot a network connectivity issue. Just giving you as much information as I can.

We do run jobs with hundreds of thousands of records, and with large images. As for 200 data fields, I don't think we have a job like that. Is FusionPro really using all those fields?

 

Yes in fact it is. It's quite complicated and we've spent the better part of the past 6 months simplifying where we can but overall it is what it is. Complex.

 

Okay, well, I don't know exactly what correspondence you have had with Support. But you can't just call up the auto shop and tell them that your car is making a funny noise, and demand that they diagnose the problem over the phone. Why would something suddenly stop working? I don't know. I would have to start by asking you what changed on your system.

 

To get you up to speed on that Dan, nothing known changed. We've gone back and reinstalled FusionPro on the Macbook after the fact in an attempt to get it "working" again. (Note that working refers to being able to compose 50,000 records not the actual 100k+ file that we should be using) No change in behavior after a reinstall.

 

Also, do you mean that FusionPro won't compose those 50,000 records directly on your Mac, or that it won't compose them via Producer?

 

We never compose directly, only through the producer (API).

Link to comment
Share on other sites

I'm not suggesting that I can troubleshoot a network connectivity issue. Just giving you as much information as I can.

That's fine, but information about the operating system and FusionPro version on every machine in the Producer system would be more relevant.

Yes in fact it is. It's quite complicated and we've spent the better part of the past 6 months simplifying where we can but overall it is what it is. Complex.

Okay. I know that in older versions of FusionPro, having a lot of data fields could cause problems. Those have been fixed in FusionPro 9, as far as I know. At any rate, it seems that the problem isn't the number of fields per se, it's the overall size of the data file, and only in the transmission of the file from the client Mac to the Producer server, not in the composition itself.

To get you up to speed on that Dan, nothing known changed. We've gone back and reinstalled FusionPro on the Macbook after the fact in an attempt to get it "working" again. (Note that working refers to being able to compose 50,000 records not the actual 100k+ file that we should be using) No change in behavior after a reinstall.

Well, FusionPro hasn't changed, if you're installing the same version. So it must be something else outside of what we at PTI can control. Since it does appear to be a problem with sending the data file over the network, I would look at some kind of network setting or policy that may have changed.

We never compose directly, only through the producer (API).

Well, you could try composing directly on your Mac.

Link to comment
Share on other sites

That's fine, but information about the operating system and FusionPro version on every machine in the Producer system would be more relevant.

 

 

Both machines are running OS X 10.8.5

 

Both are running Acrobat 11.0.06 and FusionPro 9.0.3 The FusionPro Server is running on a Windows Server 2008 R2 Standard Service Pack 1 32GB ram. 64 Bit OS.

Okay. I know that in older versions of FusionPro, having a lot of data fields could cause problems. Those have been fixed in FusionPro 9, as far as I know. At any rate, it seems that the problem isn't the number of fields per se, it's the overall size of the data file, and only in the transmission of the file from the client Mac to the Producer server, not in the composition itself.

[/Quote]

 

I would agree with this statement.

Well, FusionPro hasn't changed, if you're installing the same version. So it must be something else outside of what we at PTI can control. Since it does appear to be a problem with sending the data file over the network, I would look at some kind of network setting or policy that may have changed.[/Quote]

 

No one is suggesting that something has changed with FusionPro. We're looking for help figuring out where to look on our end for issues. As I've said before both machines are on the same network and one is still working and the other not.

 

Well, you could try composing directly on your Mac.

 

I could try that but that would defeat the purpose of why we purchased the FuisionPro API in the first place.

 

Let me reiterate the concern here.

 

1). Neither machine can produce the 100k + record file through the API server.

2). One machine now fails to do even 50k. This concerns me as it shows some sort of degradation and our work is very deadline oriented. I can't have it fail altogether.

 

The goal is to get both machines working properly and composing the entire 100k record file.

Link to comment
Share on other sites

Both machines are running OS X 10.8.5

 

Both are running Acrobat 11.0.06 and FusionPro 9.0.3 The FusionPro Server is running on a Windows Server 2008 R2 Standard Service Pack 1 32GB ram. 64 Bit OS.

And the Windows machine is running what version of FusionPro? (Yes, I mean the operating system and FusionPro version on every machine in the system.)

No one is suggesting that something has changed with FusionPro. We're looking for help figuring out where to look on our end for issues.

Sure, but it's hard for us to know what kinds of network policies you have set up on your end.

As I've said before both machines are on the same network and one is still working and the other not.

So you have two Macs, both with the same version of OS X and FusionPro, connecting to the same Producer Scheduler, and only one of them is able to submit the job with the large data file? Are they both connecting to the network in the same way?

I could try that but that would defeat the purpose of why we purchased the FuisionPro API in the first place.

You didn't purchase the Producer API (Server), you purchased Producer (Direct). Or, if you did purchase Producer API, there are better ways you can do this.

Let me reiterate the concern here.

 

1). Neither machine can produce the 100k + record file through the API server.

2). One machine now fails to do even 50k. This concerns me as it shows some sort of degradation and our work is very deadline oriented. I can't have it fail altogether.

 

The goal is to get both machines working properly and composing the entire 100k record file.

Of course. We want it to work for you as well. But it may not be something that can be analyzed without taking a closer look at your system. It's almost certainly not something that can be analyzed in the context of this user forum.

 

There may be more efficient ways to set things up with your job as well, such as to put some files in a shared network location which the composition running on the Windows server would be able to access via UNC paths, instead of piped over the TCP connection between the Monitor app and the Scheduler. Having to send that huge data file over every time is like driving around with a trunk full of rocks. But a fully automated solution, where you can invoke the composition using arbitrary files, requires the Producer API (FP Server).

Link to comment
Share on other sites

Dan I appreciate your feedback.

 

And the Windows machine is running what version of FusionPro? (Yes, I mean the operating system and FusionPro version on every machine in the system.)

 

V9.0.3 on the server as well Dan.

 

Sure, but it's hard for us to know what kinds of network policies you have set up on your end.

So you have two Macs, both with the same version of OS X and FusionPro, connecting to the same Producer Scheduler, and only one of them is able to submit the job with the large data file? Are they both connecting to the network in the same way?

 

2 Macs and 1 Windows 7 PC. All running FusionPro 9.0.3 and connecting to the same Producer Scheduler. All on the same network. All machines using the same connection settings.

 

Mac #1 Can print the 50k file but not the 100k file

Mac #2 Cannot print the 50k file or the 100k file

(This machine could previously print the 50k file)

PC#1 Can print the 50k and the 100k file.

 

Support (Alex) gave us the workaround of composing a small file and then recomposing from the scheduler application with the larger file. This works with the 50k on both Macs and the PC. This does not work with the 100k file on either Mac but does work with the 100k file on the PC.

 

No known changes were made to Mac#2 before it stopped working with the 50k file.

 

You didn't purchase the Producer API (Server), you purchased Producer (Direct). Or, if you did purchase Producer API, there are better ways you can do this.

My apologies on the confusion.

Of course. We want it to work for you as well. But it may not be something that can be analyzed without taking a closer look at your system. It's almost certainly not something that can be analyzed in the context of this user forum.

 

There may be more efficient ways to set things up with your job as well, such as to put some files in a shared network location which the composition running on the Windows server would be able to access via UNC paths, instead of piped over the TCP connection between the Monitor app and the Scheduler. Having to send that huge data file over every time is like driving around with a trunk full of rocks. But a fully automated solution, where you can invoke the composition using arbitrary files, requires the Producer API (FP Server).

Link to comment
Share on other sites

Well this is the response from support at this point.

 

"Unfortunately, I can offer no other solution than to reiterate our software development team's suggestion that using a 200 MB data file is not

within the supported design parameters of Fusionpro VDP Producer. The data file must remain at a manageable size for the software to work effectively."

 

So this would mean that there is in fact a size limit to the data file that can be used in FusionPro. At least on a Mac.

 

What still concerns me however is that this was working just fine until 3 weeks ago and I can in fact use this file another Mac sitting 10 ft from this one. So further degradation is possible and would quickly become unworkable.

Link to comment
Share on other sites

Well this is the response from support at this point.

 

"Unfortunately, I can offer no other solution than to reiterate our software development team's suggestion that using a 200 MB data file is not

within the supported design parameters of Fusionpro VDP Producer. The data file must remain at a manageable size for the software to work effectively."

 

So this would mean that there is in fact a size limit to the data file that can be used in FusionPro. At least on a Mac.

 

What still concerns me however is that this was working just fine until 3 weeks ago and I can in fact use this file another Mac sitting 10 ft from this one. So further degradation is possible and would quickly become unworkable.

Yes, unfortunately, everything has its limits. You also mentioned "degradation" in your note to Support, saying, "Today it's a problem with 200mb files but maybe by next week we are down to 100mb. " While I don't think that's true, as your own testing shows that the limitation with the Mac APIs seems to be quite consistent, that question could also be turned around the other way: How large of a file do you expect that the software should be able to support? That is, how large a file do you think we should test with? 200 MB? 500 MB? A gigabyte? What is the upper limit? What do you think it should be? It can't be infinity, so there has to be a finite limit somewhere.

 

Also, you're the first user I know of to actually hit this limit, which is why our Support engineers were not able to properly diagnose the problem right away. I apologize for the confusion.

 

As to why one of your Macs used to be able to exceed that limit in the past but can't now, like I said before, if the FusionPro software itself hasn't changed, then something else about the machine or its configuration must have changed, but I have no way of knowing what that might be, especially since the old configuration is no longer available for comparison. Maybe it was a software update to the operating system.

 

The other thing I will reiterate is that I strongly suspect that there's a more efficient way to set up your job so that it doesn't require 200 data fields. But I would have to see at least a few records of the data file to be able to offer any specific suggestions.

 

However, the bottom line is that, for the kind of volume you're composing, FusionPro VDP Producer API (Server) is a more appropriate solution than Producer (Direct).

Link to comment
Share on other sites

Yes, unfortunately, everything has its limits. You also mentioned "degradation" in your note to Support, saying, "Today it's a problem with 200mb files but maybe by next week we are down to 100mb. " While I don't think that's true, as your own testing shows that the limitation with the Mac APIs seems to be quite consistent, that question could also be turned around the other way: How large of a file do you expect that the software should be able to support? That is, how large a file do you think we should test with? 200 MB? 500 MB? A gigabyte? What is the upper limit? What do you think it should be? It can't be infinity, so there has to be a finite limit somewhere.

 

My expectation for what the limit should be aside, I would expect it to remain stable. Clearly that is not the case as one machine has become more limited and the other has begun to occasionally display the same behavior. This is why I stated that further degradation seemed possible if not likely.

 

Also, you're the first user I know of to actually hit this limit, which is why our Support engineers were not able to properly diagnose the problem right away. I apologize for the confusion.

 

Someone is always the first. This is why we made this post to the community in the beginning to see if any other users had experienced a similar issue. That's the great thing about a forum, getting user feedback from the field and not just what support does or doesn't know.

 

As to why one of your Macs used to be able to exceed that limit in the past but can't now, like I said before, if the FusionPro software itself hasn't changed, then something else about the machine or its configuration must have changed, but I have no way of knowing what that might be, especially since the old configuration is no longer available for comparison. Maybe it was a software update to the operating system.

 

I checked the install logs on this machine personally to look for any updates and was unable to find anything that had changed prior to the issue developing. We were hoping that support may have had some experience with the issue to point us towards a likely cause only.

 

The other thing I will reiterate is that I strongly suspect that there's a more efficient way to set up your job so that it doesn't require 200 data fields. But I would have to see at least a few records of the data file to be able to offer any specific suggestions.

 

However, the bottom line is that, for the kind of volume you're composing, FusionPro VDP Producer API (Server) is a more appropriate solution than Producer (Direct).

 

I'd be happy to send you the actual template file to review Dan. We are working with our IT department to try to remove any unnecessary fields in the data. I don't suspect that there as many to remove as you might think however. The job is extremely complex. We have been working to reduce the rulesets in the templates over the past few months to simplify the overall project. We continuously review these.

 

I will look into the API version of the software. I was not with the company when Producer was purchased but my understanding is that was the recommended product for our project at the time.

Link to comment
Share on other sites

My expectation for what the limit should be aside, I would expect it to remain stable. Clearly that is not the case as one machine has become more limited and the other has begun to occasionally display the same behavior. This is why I stated that further degradation seemed possible if not likely.

Sure, I understand. Although sometimes things like the upper limits of how much memory you can allocate, or how much data you can push over TCP/IP, are transient. That is, the limitation is sometimes dependent on external factors. I'm not sure exactly what those factors are in this case, though.

 

On the other hand, you seem to be hitting the same limit pretty consistently. If there were a general problem with, say, 50 MB collected templates, we would have heard about that from other users.

Someone is always the first. This is why we made this post to the community in the beginning to see if any other users had experienced a similar issue. That's the great thing about a forum, getting user feedback from the field and not just what support does or doesn't know.

Yes, that is the great thing about this community, and your reaching out to it was completely appropriate. But at some point, I think it's safe to assume that we (at PTI) know more about the inner workings of our software than any of your fellow users do. Also, the fact that nobody else, as far as I know, has run into this problem, suggests to me that there's something unusual about the job, which can probably be reworked. That, and the 200 data fields.

 

If nothing else, you have definitely exceeded the file size that we expect to be able to support, and that we regularly do QA testing with, at least for Producer. We do test with much larger data files with Server (Producer API). And in fact, the composition engine itself has no known upper limit in regards to data file size. The problem here is all about sending data from the Mac client to the Windows server. Once the files are there on the composition machine, the job should compose just fine, and you have verified that it indeed does.

I checked the install logs on this machine personally to look for any updates and was unable to find anything that had changed prior to the issue developing. We were hoping that support may have had some experience with the issue to point us towards a likely cause only.

Well, it might not be something that was logged. Like I said, it's probably impossible to figure out now, especially since the old configuration is no longer available for inspection.

 

I've also been working with customers long enough to know that sometimes things are not reported accurately. Not that I don't believe you that it used to work on the same machine, but there may be something else going on.

 

I can tell you that there's no intentional limit that we build into the software in this regard. The root of the problem is that we're using some older APIs on Mac, and Apple does not spend a lot of effort making sure that older APIs and applications work correctly as OS X is updated. This is a lot different than how, say, Microsoft operates.

I'd be happy to send you the actual template file to review Dan. We are working with our IT department to try to remove any unnecessary fields in the data. I don't suspect that there as many to remove as you might think however. The job is extremely complex. We have been working to reduce the rulesets in the templates over the past few months to simplify the overall project. We continuously review these.

Like I said, a few lines might give me an idea of what you're doing, and where things can be refactored. But please feel free to send the template to Support. They can provide you with an FTP site to upload it.

I will look into the API version of the software. I was not with the company when Producer was purchased but my understanding is that was the recommended product for our project at the time.

Well, when your company purchased the product, it probably was appropriate solution, since you were not using 200 MB data files.

 

Again, the whole issue is just in transmitting the file from the Mac to the Windows server. The other way I think you could work around the problem, besides refactoring the job to not need 200 data fields, is by making some fairly minor adjustments to your workflow. For instance, you could continue to manage the template on Mac, and run smaller jobs via Producer to test template design changes, while for production runs, you could go over to a Windows machine and do a Recompose with the larger data files. (If it were me, I would probably use Remote Desktop in this setup, to be able to access the Windows machine from the Mac.)

 

But, as you get into more and more volume, even if the problem you're having now were fixed, and even with your gigabyte Ethernet, you're likely still going to outgrow that Producer workflow, where a human has to push a button to run a job, and want to be able to move to a more automated workflow, which is what the Producer API/Server is really all about.

Link to comment
Share on other sites

Just to summarize and wrap this up:

 

The limitation you're running into is not going to be fixed any time soon. At some point, hopefully later this year, we plan to rework the architecture of the entire FusionPro VDP Producer system, especially the Mac client, which does not work on Mac OS X 10.9 Mavericks at all, even with the new (soon to be released) FusionPro VDP 9.2, which otherwise fully supports Mavericks. When we do this re-architecture of Producer, it's likely that the current limitation will be moot, as it's a consequence of the older Mac APIs we're currently using. There will still be some finite upper limit to the amount of data you can upload from the client Mac or Windows machine to the Scheduler machine, at least in the files we use to test, but it will likely be higher than the 200 MB or so limit imposed by the older Mac APIs.

 

We have offered you three different suggestions to work around the limitation:

 

  1. Modify your workflow so that you continue to do design work on the template on Mac, but submit the job for production runs via the Producer Monitor app on Windows (with the "Recompose" button).
  2. Refactor the template to use a smaller data file, with fewer than 200 fields. We have repeatedly offered to help you with this. All you need to do is send us the template.
  3. Use FusionPro VDP Producer API (FP Server), which will open up the possibility of a fully automated workflow, which it sounds like you want to be moving towards anyway.

That's about all we can offer you at this time. This is the official word from Engineering. There's nobody else at PTI, either in Support or Engineering, who is going to be able to offer you any further suggestions.

 

Hopefully one of the aforementioned suggestions will be a suitable resolution for you.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...