Patch Set 5: Code-Review-1
(1 comment)
We hit this issue in one of our installations, so I'm glad to see a work to
resolve this. In that case though, we just increased the length of the
automatically generated extensions to make sure they never overflow.
Patch Set 5:
> deferring to neels on this one. as the patch has been sitting in
> the queue for quite some time: Ping?
I've created https://osmocom.org/issues/2595
It's not a simple as it looks, so I
suggest this patch be abandoned until the solution is decided upon.
--
To view, visit
Patch Set 5:
deferring to neels on this one. as the patch has been sitting in the queue for
quite some time: Ping?
--
To view, visit https://gerrit.osmocom.org/3910
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id:
Patch Set 5:
> Actually something other than +1 (maybe something random here)
> would avoid sequential numbers if desired.
ah sure, the +1 selects only the adjacent missing numbers, so if there aren't
more than one scattered gaps, we will again create sequential numbers. Not the
complete
Patch Set 5:
> >
> > That could work, right?
>
> OK this will give you a random available extension:
>
> SELECT t.extension+1, t2.extension AS ext
> FROM subscriber AS t
> LEFT OUTER JOIN subscriber AS t2 ON
> t.extension+1 = t2.extension
> WHERE t2.extension IS NULL
> ORDER BY
Patch Set 5:
>
> That could work, right?
OK this will give you a random available extension:
SELECT t.extension+1, t2.extension AS ext
FROM subscriber AS t
LEFT OUTER JOIN subscriber AS t2 ON
t.extension+1 = t2.extension
WHERE t2.extension IS NULL
ORDER BY RANDOM() LIMIT 1;
--
Patch Set 5:
To avoid loops altogether, I'm thinking of an SQL approach:
One part of the solution is the random picking:
SELECT * FROM table ORDER BY RANDOM() LIMIT 1;
The other part would be to select from a list of *unused* values.
This one looks promising:
Patch Set 5:
> So if your
> problem goes away from using sqlite directly,
Hmm. the gerrit failure was related to libdbi 0.8.4, but that is not related to
the issue I'm trying to address, although I'm not sure - will this code fail
now on a system with libdbi 0.8.4?
> but it has
> to
Patch Set 5:
(1 comment)
https://gerrit.osmocom.org/#/c/3910/5/openbsc/src/libmsc/db.c
File openbsc/src/libmsc/db.c:
Line 1442: for (i = 0; i < (smax - smin)*2; i++) {
Is there a way to check the entire pool for a free extension, without going
through them all one by one?
Given that we
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/3910
to look at the new patch set (#5).
libmsc: db_subscriber_alloc_exten() remove infinite loop
This patch prevents entering an infinite loop in the
case that you actually have exhasuted
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/3910
to look at the new patch set (#4).
libmsc: db_subscriber_alloc_exten() remove infinite loop
This patch prevents entering an infinite loop in the
case that you actually have exhasuted
Patch Set 3:
In this discussion I'd also like to plug the forward perspective that all
subscriber management will move to osmo-hlr, where we also are not using libdbi
anymore for its cumbersomeness. So if your problem goes away from using sqlite
directly, consider that accomodating libdbi
Patch Set 2:
Yes, I get avoiding many calls of rand().
Not sure I/we should spend so much time on this.
I spotted it and am being very nit picky, and thought it was an opportunity to
learn..
It's very unlikely one would run out of extensions, unless one did happen to
configure a very
Patch Set 2:
Ok, let me reformulate my question: Do you ever see this message after this
patch?
"Out of Trys, no extension for IMSI %s"
What I see from the code you're posting is that we now have a loop that is
limited by the number of extensions that are available, however, we still use a
Patch Set 2:
>
> Play around with it to see if it cures the neverending loop there.
Seeing your comment after I pushed last patch set..
Hmm. How could it cure the loop? You need to give up at some point if all
possibilities are exhausted, no?
--
To view, visit
Patch Set 2:
> Build Failed
>
> http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2457/ :
> FAILURE
Hmm that's annoying. must be a different libdbi or sqlite? string was the only
type I could ask libdbi for that didn't give me this error.
--
To view, visit
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/3910
to look at the new patch set (#2).
libmsc: db_subscriber_alloc_exten() remove infinite loop
This is not right, but at least it prevents entering an
infinite loop in the case that you
Patch Set 1:
I see... it's from the VTY itself that hangs with a valid configuration.
Would you send a v2 of this patch that does something like this?
... extension_alloc(...)
{
range = max - min;
extension = min + (rand() % range);
return extension
}
Then:
if extension is
Patch Set 1:
I see... it's from the VTY itself that hangs with a valid configuration.
Would you send a v2 of this patch that does something like this?
... extension_alloc(...)
{
range = max - min;
extension = min + (rand() % range);
return extension
}
Then:
if extension is
Patch Set 1:
> > (1 comment)
>
> sqlite> select count(*) from subscriber;
> count(*)
> --
> 21024
>
I guess (smax - smin) - the_above_result is your max_i in the loop at which
point you should bale?
--
To view, visit https://gerrit.osmocom.org/3910
To unsubscribe, visit
Patch Set 1:
> (1 comment)
I dunno.. I just came across this as I was taking a quick look at the failing
vty tests. I configured
subscriber-create-on-demand random 1 10010
and noticed the hang.
Here's a busy rhizomatica site:
sqlite> select count(*) from subscriber;
count(*)
Patch Set 1:
(1 comment)
https://gerrit.osmocom.org/#/c/3910/1/openbsc/src/libmsc/db.c
File openbsc/src/libmsc/db.c:
Line 1419: try = (rand() % (smax - smin + 1) + smin);
Why don't we better update this code to use something better than a random
function? To keep it simple,
Patch Set 1:
> Uploaded patch set 1.
How should this be done? If we don't go sequentially, how many times to try a
random extension before we give up?
--
To view, visit https://gerrit.osmocom.org/3910
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Review at https://gerrit.osmocom.org/3910
libmsc: db_subscriber_alloc_exten() remove infinite loop
This is not right, but at least it prevents entering an
infinite loop in the case that you actually have exhasuted
all available extensions.
Change-Id: Icf0f1e5a7f360bc27592a55890f74a9a12bc9f42
24 matches
Mail list logo
