Arquillian persistence does not work in embedded adapter but came across this
workaround solution
https://github.com/rmannibucau/persistence-with-openejb-and-arquillian .
It is based on arquillian-openejb-embedded-4 (4.6.0.1), when I try to
replace openejb with latest arquillian-tomee-embedded,
I swapped to 7.1.0 and am seeing the same thing. But I think I have a
better idea of what is going on by default when this property isn't
configured manually.
In JsonParserFactoryImpl, a system level maxSize value is set and to
default to 262144 if the max-string-length johnzon property isn't set
Francois does raise a good point about 8.0.0 Final.
We have been releasing ML versions so far and this is a good thing. On the
other hand, we cannot release ML versions indefinitely and we need to move to a
stable final version at some point.
My challenge here is, what are the minimal
It's a text messaging service, Twilio. So we can actually call their API as
many times as we want, and they will queue up messages to send out at 1
msg/sec. The problem is, even at 1msg/s, the cell phone carriers don't like
a single person sending the similar messages over and over again. So if
We did tons of fixes in Johnzon. Can you please try out TomEE-7.0.5? This
version contains a much newer version of Johnzon.
LieGrue,
strub
> Am 26.02.2019 um 20:54 schrieb Kean Erickson :
>
> Sorry to reply to my own email but one more question on that--if I am to
> set
> but this one is accessing an external resource that will error out if we
go too fast.
Out of curiosity (and because it might help with suggestions), what's the
external resource? Its "sounds" like a rate limited external webservice,
but I'm just guessing.
Sounds like we could wrap the
I know right? It's sort of funny actually. We have one instance of TomEE
processing 5k+ msg/s for another purpose, but this one is accessing an
external resource that will error out if we go too fast.
We can choke resources by limiting the pool and maxSessions, but we need
something more
Sorry to reply to my own email but one more question on that--if I am to
set "org.apache.johnzon.max-string-length", is there anywhere that the
default value for this is documented? The error message claims the default
is 8192, but if I override it in system.properties with 4092 the warning
goes
I have had that same problem before in my previous company. We did kind of
a hack at that time.
So short answer, there is nothing available to control the consuming rate.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Feb 26, 2019 at 5:53 PM Jonathan
You're consuming messages too quickly? Sounds like a good problem to have
:). I'm not aware of a rate limit facility in the connector code. You can
tweak the MDB pool to have less concurrency, and lower throughput as a
result. There was a change I made with Ivan to provide the same sort of
pooling
Here's a problem I never thought I'd have... we need to rate limit the rate
and which we process a message queue.
Is there a facility in TomEE to do this? I looked around the MDB dispatch
code and didn't see anything specifically.
Thanks,
-Jonathan
--
Sent from:
It takes a minimum of 3 days from the start of the process, and typically
one week. It can be longer if there are issues. Releasing is quite
difficult and can take multiple attempts before a vote is even put up. I
think there is general agreement that we're ready for a release. I possibly
might be
Hello Roberto,
Any release date for TomEE 8.0.0 final that, you or anyone from the dev list,
may disclose ?
Best Regards.
-Original Message-
From: Roberto Cortez [mailto:radcor...@yahoo.com.INVALID]
Sent: mardi 26 février 2019 00:01
To: users@tomee.apache.org
Subject: Re: TomEE Web vs
Yes!!! This seems to be the exact issue. I have worked around it by getting
jsonb to do a simple string to object mapping as soon as I've configured it
in my provider. Only then do I allow multiple threads to use it.
On Tue, 26 Feb 2019, 13:26 Jonathan Gallimore,
wrote:
> Hi Paul
>
> Does this
Hi,
I am trying to setup Arquillian unit tests for our EJB based REST API's. I
am getting this error:
/Caused by: java.lang.ClassNotFoundException:
org.apache.openejb.util.JuliLogStreamFactory$OpenEJBSimpleLayoutHandler
/
My dependencies are:
7.1.0
1.4.1.Final
Hi Paul
Does this (from the Johnzon mailing list yesterday):
http://mail-archives.apache.org/mod_mbox/johnzon-dev/201902.mbox/browser
sound similar to your issue?
Regards
Jon
On Tue, Feb 26, 2019 at 12:29 AM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:
> I'd be pretty surprised
16 matches
Mail list logo
